-
Notifications
You must be signed in to change notification settings - Fork 25k
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
Make msearch line format less lenient #61771
Labels
>enhancement
good first issue
low hanging fruit
:Search/Search
Search-related issues that do not fall into other categories
Team:Search
Meta label for search team
v7.9.4
v8.13.0
Comments
cbuescher
added
>enhancement
:Search/Search
Search-related issues that do not fall into other categories
v8.0.0
v7.9.2
labels
Sep 1, 2020
Pinging @elastic/es-search (:Search/Search) |
Pinging @elastic/es-search (Team:Search) |
Hi, I am a first timer and want to work on this issue, can you please give more details on how to raise a pull request? |
Hi @cbuescher , Can I give it try? It will be my first contribution. |
Hello team, |
limotova
added a commit
to limotova/elasticsearch
that referenced
this issue
Dec 9, 2023
Extra characters after msearch request lines are currently ignored. This commit adds a check for extra chars and throws an exception if found. Fixes elastic#61771
benwtrent
added a commit
that referenced
this issue
Jan 4, 2024
* Remove leniency in msearch parsing (#61771) Extra characters after msearch request lines are currently ignored. This commit adds a check for extra chars and throws an exception if found. Fixes #61771 * adding changelog entry * Fix test --------- Co-authored-by: Elastic Machine <[email protected]> Co-authored-by: Benjamin Trent <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
>enhancement
good first issue
low hanging fruit
:Search/Search
Search-related issues that do not fall into other categories
Team:Search
Meta label for search team
v7.9.4
v8.13.0
A user recently discovered that we allow training closing brackets in
_msearch
request lines (see #61353).It seems we parse only the first complete JSON object to a map, then discarding the rest of the line in MultiSearchRequest#readMultiLineFormat, allowing requests like the following:
While this is just a leniency that shouldn't affect the correct behaviour of the search, maybe we shouldn't allow this and error if we detect anything after parsing the initial json object.
The text was updated successfully, but these errors were encountered: