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
url params parsing should not be lenient #14719
Comments
++ |
I would be happy to implement this change. May I go ahead? |
@martinstuga Please do! Note that it is a large task. It means handling every rest handler (although doing in a series of smaller PRs would be just fine and easier to review). |
This validation must be implemented on every single RestHandler? I think that we can do it on a generic and less error prone way by checking if all passed params are used in the handleRequest method. Sounds good? |
Yes, what I mean is, right now I believe each reat handler just does a get on the params they use. They will need to do a remove, and then have a check at the end (in shared code) that there are no params left. |
I think there is a way to do everything with shared code. I'll implement it and then you check if it's correct. |
Sure, please do. |
I have a few questions, in the case there're wrong parameters, which behaviour should we implement? Throw an Exception? In order to keep backward compatibility, don't you think we should add an parameter to enable/disable this feature? |
Yes. Make sure the exception is translated into a 400 level error.
Do it in master and add it to the breaking changes list I think. I'm not personally a huge fan of silently ignoring parameters even in 2.x but I think it'd be quite uncontroversial to do it in 3.0. |
I've already created a PR just with the validation do GET rest requests. Thanks. |
First commit to allow the team to check if this approach is OK.
Please, anybody can give me some feedback about the PR #15462? I'm waiting for this feedback to go ahead with the other rest services (PUT, DELETE,...) Thanks. |
First commit to allow the team to check if this approach is OK.
First commit to allow the team to check if this approach is OK.
If you use eg the
_analyze
api, and mispell thetokenizer
, it will happily go on using the standard analyzer (if you have filters specified, it will ignore them as well).We should remove all leniency from url param parsing, it does not help anyone, but only causes confusion. Rest actions should remove parameters as they are parsed, and fail when there are extras left (eg
Unknown parameter "tokenzier" for _analyze
)The text was updated successfully, but these errors were encountered: