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
handle failure to upcase invalid UTF8 strings for _method
values
#1249
handle failure to upcase invalid UTF8 strings for _method
values
#1249
Conversation
cc @eileencodes I'm happy to do whatever to move this along, I don't want to have it be forgotten 🙂 |
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 don't know what is up with the CircleCI build as it's pretty new but the Travis build seems affected by your change.
test/spec_methodoverride.rb
Outdated
app.call env | ||
|
||
errors.rewind | ||
errors.read.should =~ /Invalid string for method/ |
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.
How come we're using a match here instead of should.equal
? Can it be something else other than "invalid string for method"? I think this is also making the Ruby 1.8.7 build cranky https://travis-ci.org/rack/rack/jobs/365845664#L616
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 was copying the existing style from a little further down the test:
https://github.com/mclark/rack/blob/a795740a6e071333ecc7b498fdeed24d58750da4/test/spec_methodoverride.rb#L100
I can update both of them if you like?
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 think the 1.8.7 build is probably failing because I don't think that version of ruby even supports UTF-8, so the error can't be thrown. Does rack have a standard pattern for skipping tests based on the ruby version? I suspect that might be the best solution in that case, but I'm far from an encoding expert (nor do I desire to become one! 😄 )
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.
Here's an example https://github.com/rack/rack/blob/1-6-stable/test/spec_chunked.rb#L45
But I prefer wrapping the entire test in the conditional rather than the conditional after the end like:
if RUBY_VERSION >= "1.9"
test blah blah
end
38e2efd
to
1c945e0
Compare
cc/ @tenderlove can you take a look at this when you get a chance? This was an issue we hit where someone was sending an invalid In older versions of Ruby this raises an invalid utf-8 error (which we were rescuing in our app), but in newer versions it raises a "input string invalid" (which we are raising). I suggested we fix this upstream in Rack and @mclark took on that work. I want to double check if you think this is the right place to fix the issue or if there's somewhere in Rack I didn't think of that's more appropriate. |
@eileencodes This looks like the right place. I'm concerned about encoding for the "mock request". Post data will come in over the wire with binary encoding, so I feel like this line should have a Also, looks like this PR is targeting |
Yup I was planning on porting to master / 2.0 once we had everything settled in our branch. One thing I'm not sure about is we're at 1.6.9 so I guess we need to make a 1-7-stable branch to do a new release or do we go to 1.6.9.1 or something like that? |
@eileencodes this is a bugfix, shouldn't we just release 1.6.10? Regardless, I'm OK with this fix as long as we make sure it lands on master too. 😀 |
Yea I forgot that after .9 is not .1 but .10. 😳 |
1c945e0
to
23d55d0
Compare
💯 agree. I've fixed that and force pushed. Thanks for taking a look @tenderlove. @eileencodes does this need PRs for |
If you can backport to both in new PR's that'd be awesome - otherwise I'll do it after merging this one. Some versions of Ruby don't support |
Some strings cannot be upper cased and raise an ArgumentError instead. Let's capture this error and log its occurence to the environment via rack.errors
23d55d0
to
b27dd86
Compare
@eileencodes, @tenderlove I opted to change it to |
…ters handle failure to upcase invalid UTF8 strings for `_method` values
…ters handle failure to upcase invalid UTF8 strings for `_method` values
…ters handle failure to upcase invalid UTF8 strings for `_method` values
Merge pull request #1249 from mclark/handle-invalid-method-parameters
…ters handle failure to upcase invalid UTF8 strings for `_method` values
…ters handle failure to upcase invalid UTF8 strings for `_method` values
…stable Merge pull request #1249 from mclark/handle-invalid-method-parameters
Thanks for working on this @mclark!! I merged and forwardported this to master and 2-0-stable and then released 2.0.5 and 1.6.10. |
👋 Hi folks, I recently encountered a case where a client was submitting invalid UTF8 characters in the "_method" parameter which was subsequently causing
method.to_s.upcase
to raise anArgumentError
. This pull request proposes instead logging the failure to "rack.errors" in the environment and just not overrideREQUEST_METHOD
with anything when this occurs.I originally planned on raising
Rack::Utils::InvalidParameterError
but when I sawmethod_override_param
uses"rack.errors"
I switched to that:https://github.com/mclark/rack/blob/a795740a6e071333ecc7b498fdeed24d58750da4/lib/rack/methodoverride.rb#L42-L48
I'm happy to go either way of course, but if it raises we should probably also update the docs for
InvalidParameterError
to be a little less specific toparse_nested_query
.I can open a PR on 2.0 (or master, whatever is preferred) as well if this change is desired, I was just thinking I'd let the discussion happen here first (based on
1.6-stable
) if that's cool with everyone. I guess I could have checked the process on that one first 😄