-
-
Notifications
You must be signed in to change notification settings - Fork 9.2k
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
UnicodeEncodeError handling gzipped responses on Google App Engine #2595
Comments
Have you tried requests 2.7.0? That fixed a number of problems associated with that urllib3 release. |
@Lukasa The problem happens in requests 2.7.0 as well -- all released versions after 2.6.0. The problem is in urllib3 versions before urllib3/urllib3@22a9713, so would be fixed by merging in a more recent urllib3. |
@agfor urllib3/urllib3@22a9713 should be in 2.7.0. |
@sigmavirus24 @Lukasa It looks like there are actually two different problems, and that commit only fixed one. With requests 2.6.2 / urllib3 before urllib3/urllib3@22a9713 it blows up inside requests:
but after that commit / in 2.7.0, we blow up later inside the Braintree library. This appears to be because requests has tried to convert gzipped data to Unicode as if it had already been un-gzipped, and so replaced most of it with the unicode replacement character:
example unicode code points for the response body:
Versions 2.6.0 and below work. |
Can you provide how you're using requests so that we can understand where this comes from? |
The Braintree client library calls This diff against 2.7.0 causes things to work as they did on 2.6.0 and earlier:
But I haven't had time to dig into why the content hasn't been gzip-decoded yet at this point, so I don't have a real fix. |
I really need to find a sample URL, I think. |
@sigmavirus24 @Lukasa I haven't been able to reproduce off of Google App Engine, so here is a minimal GAE repo you can test with the development environment that exhibits the problem: https://github.com/agfor/requests-2.7-appengine-fail The core of it is:
It will dump the still-gzipped response body, and the un-gzipped response body, to the logs, then blow up on the |
Aha, this is interesting. I also cannot reproduce this, so it's actually important that we're on GAE. It seems like this is going to be caused by GAE being different to stdlib Python. This means, unfortunately, that this is a urllib3 issue (requests is unlikely to be at fault here), and in particular I think GAE is screwing this up. Unfortunately, it's screwing it up silently, which is doubly bad. @shazow What's your position on GAE support in urllib3? I know requests considers it an unsupported platform... |
I'd like to support GAE on urllib3. It used to work great, then GAE changed some stuff and now it's not. :/ Needs more investigation. |
Possibly related to urllib3/urllib3#583 |
@shazow Just to close the loop, I was able to bisect the issue back to urllib3/urllib3@f21c2a2 specifically. |
Here's a theory: does GAE patch |
Here's a suggestion: Since GAE is a for-profit platform, why doesn't GAE provide support for it for OSS projects that attempt to support it? Or better yet, will they give us an environment to test against and pay us to support it? If not, I'm not certain any of us should be really supporting it. |
@agfor Ah good find, thanks. Freakin' chunked encoding, breaking errything. Does this mean GAE still works for non-chunked/non-streaming? @sigmavirus24 Lovely idea, any interest in reaching out to the GAE team and asking if they'll fund this? :P |
Alrighty, looks like we're moving this to urllib3/urllib3#618. |
There are a few possible of workarounds for this probem:
That can affect your billing so please be careful before changing it. |
braintree/braintree_python#53 originally reported the issue. It's due to using requests 2.6.1+, which pulled in a version of urllib3 including f21c2a2b73e4256ba2787f8470dbee6872987d2d, which causes the problem.
I am able to reproduce using app engine development mode when switching https://github.com/agfor/braintree-python-appengine to use requests 2.6.1+ and un-commenting out the development mode enabling code in main.py.
The text was updated successfully, but these errors were encountered: