-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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
Fix Utils.build_nested_query to URL-encode all query string fields #1989
Conversation
In the formatted query string, the field should be fully URL-encoded. The previous implementation left the square brackets as un-escaped. It was noticed that if params were provided as a nested hash it produced a different result than a hash of string fields. For example, the params { 'q[s]' => 'name' } would result in the query string: q%5Bs%5D=name but { q: { s: 'name' } } would result in: q[s]=name Both forms now produce the same correct result with fully URL-encoded params.
d20f493
to
eb27a69
Compare
I'm okay with this but it seems like a potential breaking change. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree that this could potentially be breaking, but RFC 3986 is clear that [
and ]
are reserved characters and should be percent encoded. So I think we should merge this.
…1989) In the formatted query string, the field should be fully URL-encoded. The previous implementation left the square brackets as un-escaped. It was noticed that if params were provided as a nested hash it produced a different result than a hash of string fields. For example, the params { 'q[s]' => 'name' } would result in the query string: q%5Bs%5D=name but { q: { s: 'name' } } would result in: q[s]=name Both forms now produce the same correct result with fully URL-encoded params.
Yeah, sadly it has broken tests of my Rack-based framework unclear and non-expected, just by some patch-version release. |
IIUC, one way to avoid this problem in your test is to avoid asserting the encoded representation and actually parse the URL and extract the query parameters. This should work regardless of the encoding and is probably a more robust test in general. |
* 3-0-sec: (24 commits) bump version Update changelog Fix ReDoS vulnerability in multipart parser Fix ReDoS in Rack::Utils.get_byte_ranges Forbid control characters in attributes Bump patch version. `Rack::Request#POST` should consistently raise errors. (#2010) Fix Rack::Lint error message for HTTP_CONTENT_TYPE and HTTP_CONTENT_LENGTH (#2007) Rack::MethodOverride handle QueryParser::ParamsTooDeepError (#2006) Bump patch version. Fix Regexp deprecated third argument with Regexp::NOENCODING (#1998) Update tests to work on latest Rubies. (#1999) Bump patch version. Allow passing through streaming bodies. (#1993) Remove unnecessary executable bit from test files (#1992) Fix Utils.build_nested_query to URL-encode all query string fields (#1989) Trim trailing white space throughout the project (#1990) Fix some typos (#1991) Remove leading dot to fix compatibility with latest cgi gem. (#1988) Fix outdated Rack::Builder rdocs and remove Lobster references (#1986) ...
The behaviour changed in Rack 3 with - rack/rack#1989 - rack/rack@ab1f1c1
The behaviour changed in Rack 3 with - rack/rack#1989 - rack/rack@ab1f1c1
The behaviour changed in Rack 3 with - rack/rack#1989 - rack/rack@ab1f1c1
The behaviour changed in Rack 3 with - rack/rack#1989 - rack/rack@ab1f1c1
The behaviour changed in Rack 3 with - rack/rack#1989 - rack/rack@ab1f1c1
I can agree. I've checked the tests again. It's simple tests for Maybe I should add |
I think this is probably the correct approach. |
The behaviour changed in Rack 3 with - rack/rack#1989 - rack/rack@ab1f1c1
The behaviour changed in Rack 3 with - rack/rack#1989 - rack/rack@ab1f1c1
The behaviour changed in Rack 3 with - rack/rack#1989 - rack/rack@ab1f1c1
The behaviour changed in Rack 3 with - rack/rack#1989 - rack/rack@ab1f1c1
The behaviour changed in Rack 3 with - rack/rack#1989 - rack/rack@ab1f1c1
The behaviour changed in Rack 3 with - rack/rack#1989 - rack/rack@ab1f1c1
The behaviour changed in Rack 3 with - rack/rack#1989 - rack/rack@ab1f1c1
The behaviour changed in Rack 3 with - rack/rack#1989 - rack/rack@ab1f1c1
In the formatted query string, the field should be fully URL-encoded. The previous implementation left the square brackets as un-escaped.
It was noticed that if params were provided as a nested hash it produced a different result than a hash of string fields. For example, the params
would result in the query string:
but
would result in:
Both forms now produce the same correct result with fully URL-encoded params.