Response GZipped even when no 'accept-encoding' is defined?

[dinvlad]

Hi Team,

It seems that when I don't set accept-encoding header, or set it to '', it always returns a Gzipped (and base64-encoded) response. Is that intended behavior? It seems that if the client doesn't explicitly request encoding, we shouldn't compress the response (even if it exceeds the size threshold).

Thanks

P.S. Sorry but I'm a bit new to encoding - perhaps this has been explained already, but reading through other issues I didn't get a clear picture of how it works.

[brettstack]

You control how/when to gzip in your app.

This library will base64 encoded responses when the content-type matches one you specify in the binaryMimeTypes list (third param of createServer). In order for this to be encoded correctly in the final response to the client, you must also specify your binary mime types on API Gateway.

Replied to your comment in #39 also which I assume is the same issue.

[brettstack]

The response flow looks like:

Express response -> compression/gzip middleware (if you use it) -> aws-serverless-express (encodes to base64 if content-type is specified in binaryMimeTypes in Lambda handler) -> API Gateway (decodes base64 if content-type matches a binary mime type specified on API) -> Client

If client receives base64, it indicates your API binary support needs to be configured and redeployed.

[dinvlad]

Thanks @brettstack, I've already configured API Gateway through Swagger with SAM, similar to how it is done in the example. That is, my Swagger template contains:

x-amazon-apigateway-binary-media-types:
  - application/json

at its root, and my code contains

const binaryMimeTypes = [
  'application/json',
];
const server = awsServerlessExpress.createServer(app, null, binaryMimeTypes)

I've also made sure that changes to the API have been applied through the SAM stack. My list of binary types for this API in the Console indeed contains application/json. The only other thing I could think of is that SAM somehow didn't re-deploy these changes to the stage even though it applied them to the API resource itself.
EDIT: I re-deployed it manually and that had no effect..

[dinvlad]

Ok sorry for trouble, it seems that API Gateway doesn't understand application/json in its list of binary types. When I switched it to '*/*', it started working! Both when I send accept-encoding and when I don't.

[dinvlad]

I guess the after-thought question is, why does API Gateway ignore application/json and only accept */*?

[brettstack]

Try sending Accept header with application/json

…

On Thu, May 11, 2017, 7:37 PM Denis Loginov ***@***.***> wrote: I guess the after-thought question is, why does API Gateway ignore application/json and only accept */*? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#74 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABy6l3S11x47Od7eJJXY3k9732eX0mKvks5r48YDgaJpZM4NYuWW> .

[dinvlad]

I swear I've tried that before, but now it works too, thanks!
I also was under impression that API Gateway would assume 'application/json' automatically if Accept is omitted, at least according to these docs: http://docs.aws.amazon.com/apigateway/latest/developerguide/request-response-data-mappings.html#transforming-request-response-body
It looks like that doesn't apply in this case (either because of binary support or the library or proxy integration).

[brettstack]

Correct, mapping templates to not apply to Lambda Proxy

[enapupe]

I still think there's an issue regarding Accept-Enconding headers. The same mime type should have two different outputs depending on the Accept-Encoding header:
If a client accepts gzip, then a mime type application/javascript will for sure reply with a binary content. But if the client request does not accept a gzipped file, it will still be served a [broken] binary file, because we specified that this mime type should be handled as such.