Skip to content
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

All responses are base64 encoded #1605

Open
joeldentici opened this issue Sep 11, 2018 · 6 comments
Open

All responses are base64 encoded #1605

joeldentici opened this issue Sep 11, 2018 · 6 comments

Comments

@joeldentici
Copy link

It seems that Zappa always responds with a base64 encoded string for the response body and "isBase64Encoded" set to true.

The relevant file is the "handler.py" file provided/generated by Zappa.

On line 513, we have this if statement:

if not response.mimetype.startswith("text/") \
    or response.mimetype != "application/json":

The condition's negation is:

response.mimetype.startswith("text/") and response.mimetype == "application/json"

Clearly this is a contradiction, so the condition itself is a tautology. The true branch is taken and Zappa will always base64 encode responses.

It seems that the intention of the condition is to NOT base64 encode responses that are text (but to take a conservative approach to determine what is "text").

It seems that what we want is to NOT base64 encode when this condition is true:

response.mimetype.startswith('text/') or response.mimetype == 'application/json'

If this is the case, the condition starting on line 513 should instead be:

not response.mimetype.startswith('text/') and response.mimetype != 'application/json'

I noticed this while using Zappa 0.46.2

@erindan
Copy link

erindan commented Nov 19, 2018

Worth noting that this encoding bug seemingly makes it impossible to do API Gateway level compression of responses. Perhaps this needs a priority bump?

@55octet
Copy link

55octet commented Apr 15, 2019

This seems like a pretty big bug. I was unable to get anything but base64 responses until I disabled binary_support.

@vitodsk
Copy link

vitodsk commented Sep 11, 2019

+1
In my case this problem was preventing to have a normal deployment on AWS using Api Gateway Lambda proxy integration. There was a 40% overhead due to the computation of the encoding/decoding.

@ronenh
Copy link

ronenh commented Oct 9, 2019

I ran into the same issue and worked around it by adding "binary_support": false to my zappa_settings.json.
I suppose this may not work if any of your API endpoints do in fact return binary content but that wasn't the case for me.

@monkut
Copy link

monkut commented Dec 18, 2019

Just want to note that the "Binary Media Types" RestAPI Settings for the ApiGateway if defined as "/" may cause APIGateway to encode incoming request.body to b64.

@monkut
Copy link

monkut commented Oct 6, 2020

I put a PR together to work on some of the issues around this. It may only work for my use case though...

#2170

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants