-
Notifications
You must be signed in to change notification settings - Fork 961
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
httparty trying to json parse string w/ invalid byte sequence #541
Comments
As long as the charset is a known one according to Ruby's matching algorithm (which appears to be case insensitive and also includes aliases), we should use that encoding. Fixes jnunemaker#542 (and maybe jnunemaker#541 as well)
Any more info you can provide would be helpful. Without some idea of the raw response I'm not sure how to fix it. |
Or, since 0.15.5 is still latest, I'll wait for the next release and test with that. |
0.15.6 is out. Please try and let me know. |
Unfortunately, I'm seeing this issue on 0.15.6. I'm not able to figure out the exact piece of data causing issues, but here's a partial stack trace in case that might help.
Here's a VCR recording of this type of interaction:
Thank you for your work on httparty! |
I'd like to state my lack of knowledge in this area for the record. 😄 This feels like a different problem than the BOM stuff. I googled "\u001F\x8B\b" and it made me wonder if this is somehow related to gzipping. If anyone could get me something repeatable, I'd be happy to dig in. |
@deep-spaced any chance you tried updating the vcr recording? Just curious if that makes a difference. |
I've verified that my issue is still present in 0.15.6. I've also narrowed down what's going on. Here is some debug, with sensitive data removed:
And here's the back trace:
Our application code looks like:
Our versions: Ruby 2.4.3 It's possible this is a duplicate of issue #562. I haven't gone back and tested the other 0.15.x releases, but I can tell you we don't run into this with 0.14.0. To test whether gzip was the problem, I commented out the line in our code where we set the "Accept-Encoding" header and re-tested. Still broke. New back trace:
The debug written to stdout:
|
Previously we were experiencing the issue in #533, so I had us pinned to 0.14.0. Since that was fixed, I removed the pin and tested with 0.15.5. Now I'm getting:
Exception Backtrace: 822: unexpected token at '^_�^H'
/usr/local/rvm/gems/ruby-2.2.4/gems/json-1.8.6/lib/json/common.rb:155:in
parse' /usr/local/rvm/gems/ruby-2.2.4/gems/json-1.8.6/lib/json/common.rb:155:in
parse'/usr/local/rvm/gems/ruby-2.2.4/gems/httparty-0.15.5/lib/httparty/parser.rb:123:in
json' /usr/local/rvm/gems/ruby-2.2.4/gems/httparty-0.15.5/lib/httparty/parser.rb:143:in
parse_supported_format'/usr/local/rvm/gems/ruby-2.2.4/gems/httparty-0.15.5/lib/httparty/parser.rb:108:in
parse' /usr/local/rvm/gems/ruby-2.2.4/gems/httparty-0.15.5/lib/httparty/parser.rb:67:in
call'/usr/local/rvm/gems/ruby-2.2.4/gems/httparty-0.15.5/lib/httparty/request.rb:383:in
parse_response' /usr/local/rvm/gems/ruby-2.2.4/gems/httparty-0.15.5/lib/httparty/request.rb:351:in
block in handle_response'/usr/local/rvm/gems/ruby-2.2.4/gems/httparty-0.15.5/lib/httparty/response.rb:25:in
call' /usr/local/rvm/gems/ruby-2.2.4/gems/httparty-0.15.5/lib/httparty/response.rb:25:in
parsed_response'When I revert to 0.14.0 this same call works. I'll try to dig up the raw response we get, but it will take some work.
The text was updated successfully, but these errors were encountered: