2 個答案
- 最新
- 最多得票
- 最多評論
0
If your Lambda function is already compressing the result then you need to use a different way to return the larger payload to the client that doesn't involve API Gateway.
The most commonly used way of doing this is to have the Lambda function upload the object to S3; then generate a pre-signed URL and return that to the client. After a specific period of time, delete the object in S3 (you might also do this with lifecycle policies).
0
See: https://mxro.medium.com/compression-for-aws-http-api-gateway-a86ad8d39ada A similar set of steps may be followed for the REST API. Note: Make sure you check the accept-encoding header that was sent with the request before sending the response.
已回答 1 年前
相關內容
AWS 官方已更新 2 年前- AWS 官方已更新 2 年前
- AWS 官方已更新 2 年前
Sorry if I wasn't clear on what is happening now vs what I would like to happen. Right now there is no compression going on in the Lambda. If I turn on the API Gateway compression option, everything works fine in the sense that the client sends the right headers and the API Gateway respects those headers and does whatever it needs to do. But that built-in functionality still accepts the current uncompressed output from the Lambda function, which still has the 6+MB limit. What I was hoping for is the "manual" approach to doing what API Gateway does when you enable the built-in setting. i.e., I'll compress in my Lambda, but then I need to know what to do to the API Gateway so that the compressed data it is receiving from the Lambda gets passed on through to the requesting client with the same kinds of headers etc. so that it knows to decompress it.