binary_support logic in handler.py (0.51.0) broke compressed text response #2080
Comments
martinv13
changed the title
|
I stumbled on this while setting up a project with whitenoise. The workaround is to not use the whitenoise storages. Instead, I used the setting: |
suriya
added a commit
to suriya/Zappa
that referenced
this issue
Jul 25, 2020
When Zappa receives a compressed text/plain response from the application, it tries to process it as a text response. Instead, Zappa should treat the response as if it were a binary one and base-64 encode the response body. See issue Miserlou#2080 binary_support logic in handler.py (0.51.0) broke compressed text response Miserlou#2080
This was referenced Feb 20, 2021
suriya
added a commit
to suriya/Zappa
that referenced
this issue
Jul 17, 2021
When Zappa receives a compressed text/plain response from the application, it tries to process it as a text response. Instead, Zappa should treat the response as if it were a binary one and base-64 encode the response body. See issue Miserlou#2080 binary_support logic in handler.py (0.51.0) broke compressed text response Miserlou#2080
suriya
added a commit
to suriya/Zappa-1
that referenced
this issue
Jul 17, 2021
When Zappa receives a compressed text/plain response from the application, it tries to process it as a text response. Instead, Zappa should treat the response as if it were a binary one and base-64 encode the response body. See issue #2080 binary_support logic in handler.py (0.51.0) broke compressed text response Miserlou/Zappa#2080
zeevt
pushed a commit
to zeevt/Zappa-1
that referenced
this issue
Oct 4, 2021
When Zappa receives a compressed text/plain response from the application, it tries to process it as a text response. Instead, Zappa should treat the response as if it were a binary one and base-64 encode the response body. See issue #2080 binary_support logic in handler.py (0.51.0) broke compressed text response Miserlou/Zappa#2080
zeevt
pushed a commit
to zeevt/Zappa-1
that referenced
this issue
Oct 14, 2021
When Zappa receives a compressed text/plain response from the application, it tries to process it as a text response. Instead, Zappa should treat the response as if it were a binary one and base-64 encode the response body. See issue #2080 binary_support logic in handler.py (0.51.0) broke compressed text response Miserlou/Zappa#2080
|
what is the resolution for this issue. it seems to be a that using gzip compression is very common place. |
|
I worked around this issue by removing the GZip middleware: # settings.py
MIDDLEWARE = [
...
# 'django.middleware.gzip.GZipMiddleware', # Seems to have issues with Zappa
... |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Context
The
binary_supportsetting used to allow compressing response at application level (for instance usingflask_compress) in version 0.50.0. As of 0.51.0 it no longer works.Expected Behavior
Compressed response using flask_compress should be possible.
Actual Behavior
In
handler.py, response is forced throughresponse.get_data(as_text=True), which fails for compressed payload, thus throwing an error. This is due to the modifications in #2029 which fixed a bug (previously all responses where base64 encoded), but introduced this one.Possible Fix
A possibility would be to partially revert to the previous version and just change in
handler.pythe "or" for a "and" in the following condition:not response.mimetype.startswith("text/") or response.mimetype != "application/json"). I can propose a simple PR for this.Steps to Reproduce
Configure Flask with flask_compress; any text or json response will fail with the following error:
'utf-8' codec can't decode byte 0x8b in position 1: invalid start byteYour Environment
zappa_settings.json: relevant option: binary_support: trueThe text was updated successfully, but these errors were encountered: