binary_support logic in handler.py (0.51.0) broke compressed text response

[martinv13]

Context

The binary_support setting used to allow compressing response at application level (for instance using flask_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 through response.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.py the "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 byte

Your Environment

• Zappa version used: 0.51.0
• Operating System and Python version: Python 3.7 on Lambda
• Your zappa_settings.json: relevant option: binary_support: true

[ipmb]

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:

STATICFILES_STORAGE = "django.contrib.staticfiles.storage.ManifestStaticFilesStorage"

[timj98]

what is the resolution for this issue. it seems to be a that using gzip compression is very common place.

[kulor]

I worked around this issue by removing the GZip middleware:

# settings.py
MIDDLEWARE = [
 ...
 # 'django.middleware.gzip.GZipMiddleware', # Seems to have issues with Zappa
 ...