We have developed an application that offers serveral rest services and supports Accept-Encoding header to return compressed content through Content-Encoding:gzip header value.
This application is deployed on ec2 instances on aws and when we send a request with Accept-Encoding value set the response is correctly built.
We want to expose this api by using api gateway but it is just working for not compressing requests. When we send a request asking for gzipped content the Content-Encoding header is set correctly but the response content is corrupt.
Do we have to set some special parameter or configuration in integration response or method response steps?
Regards.
Since Dec 19, 2017. AWS API Gateway has encoding support.
After the API is created, just go to Settings and select Content Encoding Enable.
Also here is the AWS official release post.
Unfortunately, API Gateway does not currently support HTTP compression. However, it is in consideration for future development.
For now, you will need to return uncompressed content from your endpoint (i.e. omit Accept-Encoding header) in order to proxy it through API Gateway.
If it works for your use case you could alternatively base64 encode the compressed content, proxy it through API Gateway, and decode it on the client.
Thanks, Ryan
Only a workaround, but if you set Accept-Encoding: identity you should receive the result correctly (contrary to the linked discussion I have found it works for POST and GET).
I made it work by adding Accept-Encoding to AWS API Gateway Integration Request
Step 1:
Go to AWS API Gateway console, click on Integration Request
Step 2:
Add Accept-Encoding to HTTP Headers section, value 'identity' (need single quotes)
Step 3:
Click Actions -> Deploy API
If you're using AWS CloudFormation, you can add
yaml
Integration:
RequestParameters:
integration.request.header.Accept-Encoding: "'identity'
Although this question is a bit old, I'd like to add an answer since this question is top-most viewed one. In fact, there are 2 scenarios related to returning the compressed content.
The first scenario is when you want API Gateway to compress the content. As the accepted answer suggests, you can enable the content encoding on your API then deploy it.
The second scenario is your integration endpoint already compressed the result and you just want to bypass it via API Gateway. The traditional workaround was configuring it as a binary media type. However, this might be problematic since it will begin to treat all response with the media type as a binary. Additionally, if you need to deal with multiple media types, your only choice would be setting it as '*'. If you're using non-proxy integration, you will lose a chance to transform the result.
To address the second issue, now API Gateway implicitly assumes a response result as binary when a proxy integration is used AND the content is encoded (the response has Content-Encoding with the value other than 'identity'). You don't need to configure binary media types any more when these conditions are met. However, if you're returning the actual binary media (e.g. image, video), you still need to configure them as binary media type(s).
You might wonder what happens when you have both scenarios. The short answer is that API Gateway will not compress again when the response already has Content-Encoding header.
Hopefully this helps.
To allow GZipped content from HTTP proxy endpoint you can add */* in "Binary media types" found at "Binary Support" section of your API.
来源：https://stackoverflow.com/questions/39453097/how-to-return-gzipped-content-with-aws-api-gateway