Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Node blocked due to malformed JSON on _count API #26083

Closed
Matthour opened this issue Aug 7, 2017 · 1 comment

Comments

Projects
None yet
4 participants
@Matthour
Copy link

commented Aug 7, 2017

Elasticsearch version:
5.5.1

Plugins installed:
ingest-geoip, ingest-user-agent, x-pack

JVM version:
openjdk version "1.8.0_141"
OpenJDK Runtime Environment (build 1.8.0_141-b16)
OpenJDK 64-Bit Server VM (build 25.141-b16, mixed mode)

OS version:
Linux e012087cca9f 4.9.36-moby #1 SMP Wed Jul 12 15:29:07 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux

Description of the problem including expected versus actual behavior:
_count API doesn't return a 400 status "parsing_exception" error when sending data matching ".*" regex pattern.

Steps to reproduce:

docker run -p 9200:9200 -e "http.host=0.0.0.0" -e "transport.host=127.0.0.1" -d docker.elastic.co/elasticsearch/elasticsearch:5.5.1

curl -XGET -u elastic:changeme -H 'Content-Type: application/json' http://localhost:9200/*/_count -d '""'

# (don't forget to kill the container to save your CPU :-)

FYI:

  • _search works with the same data ("") returning a 400 status "parsing_exception" error
  • _count returns same error on data like a, ", etc. but the problem occurs with data matching ".*" regex pattern
@cbuescher

This comment has been minimized.

Copy link
Member

commented Aug 8, 2017

@Matthour this is indeed interesting, I just tried it on 5.2.2 and there _count and _search still give the same respone (a 400 with "parse_exception") when the request body is "".
Starting with 5.3.0, _search still returns 400 ("parse_exception") but _count doesn't return.

@colings86 colings86 added v5.5.4 and removed v5.5.3 labels Aug 25, 2017

original-brownbear added a commit to original-brownbear/elasticsearch that referenced this issue Sep 18, 2017

@cbuescher cbuescher closed this in 2db3bcc Sep 19, 2017

cbuescher added a commit that referenced this issue Sep 19, 2017

Invalid JSON request body caused endless loop (#26680)
Request bodys that only consists of a String value can lead to endless loops in the
parser of several rest requests like e.g. `_count`. Up to 5.2 this seems to have been caught 
in the logic guessing the content type of the request, but since then it causes the node to
block. This change introduces checks for receiving a valid xContent object before starting the
parsing in RestActions#parseTopLevelQueryBuilder().

Closes #26083

cbuescher added a commit that referenced this issue Sep 19, 2017

Invalid JSON request body caused endless loop (#26680)
Request bodys that only consists of a String value can lead to endless loops in the
parser of several rest requests like e.g. `_count`. Up to 5.2 this seems to have been caught 
in the logic guessing the content type of the request, but since then it causes the node to
block. This change introduces checks for receiving a valid xContent object before starting the
parsing in RestActions#parseTopLevelQueryBuilder().

Closes #26083

cbuescher added a commit that referenced this issue Sep 19, 2017

Invalid JSON request body caused endless loop (#26680)
Request bodys that only consists of a String value can lead to endless loops in the
parser of several rest requests like e.g. `_count`. Up to 5.2 this seems to have been caught
in the logic guessing the content type of the request, but since then it causes the node to
block. This change introduces checks for receiving a valid xContent object before starting the
parsing in RestActions#parseTopLevelQueryBuilder().

Closes #26083
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.