Gzip response encoding?

is it possible to enable gzip encoding with serverless?

I am setting the below headers in my serverless.yaml file, and I am seeing the two headers I specified in my response, however, the client is not able to decode the response. Also received the could not connect error when trying through postman

When I tried through API Gateway, I was able to see a full response. Any ideas on what I am doing wrong?

getImage:
handler: image.getImage
events:
- http:
path: image/{imageId}
method: get
cors: true
integration: lambda
response:
headers:
Content-Type: "ā€˜application/jsonā€™"
Content-Encoding: ā€œā€˜gzipā€™ā€

1 Like

Can you hit your getway with postman, and record the request and response and add those here. Might also be useful to see what your code is doing as well, specifically what is getting supplied to the callback.

I created another function just to test this: I did a serverless create --template aws-nodejs, then added the headers content encoding endpoint

here is the endpoint https://vrpfpzuwph.execute-api.us-east-1.amazonaws.com/dev/hi

when i try to hit it through postman, I got the ā€˜Could not get any responseā€™ error screen

That endpoint appears to be down. May want to provide some code or create a github project with a working example so people can give you some help at their convenience.

hey Matt - thanks for looking into this, issue is whenever I put ā€œContent-Encodingā€:ā€œgzipā€, the service appears offline.

When I test it through API Gateway, it works fine.

Literally all I did was create a new serverless project template, then editted the yaml file to include the below before deploying

response:
headers:
Content-Type: "ā€˜application/jsonā€™"
Content-Encoding: ā€œā€˜gzipā€™ā€

@barrytam20

Did you find a way of gzip encoding responses using serverless (lambda/api gateway)?

It is possible to gzip responses but there are a couple of limitations.
My Java framework JRestless supports it - partially i.e. for binary responses. Hereā€™s an example for it: https://github.com/bbilger/jrestless-examples/tree/master/aws/gateway/aws-gateway-binary

Since you are probably not interested in a solution for Java, let me try to explain how it works in general (for lambda proxy integration):
At the moment gzipping responses in APIGW makes - IMO - sense for binary responses, only.

This is how binary responses work:

  1. In APIGW binary responses are supported partially, only. This means you need to
    1.1. define so called binary media types
    1.2. return the binary data in the body base64 encoded from your lambda function
    1.3. flag the response with ā€œisBase64Encodedā€: true
  2. Binary media types - as far as I know - can still not be defined in serverless, so you have to define them in APIGW manually. (see the screenshots in the example mentioned)
  3. All requests to get a binary response from an endpoint must include an ā€œAcceptā€ header with one of the binary media types as value. If you donā€™t, the response body will be a base64 encoded string

So once you managed to setup binary responses, all you need to do, is to gzip your binary data before you base64 encode it and send an additional response header ā€œContent-Encoding: gzipā€ if you receive a request header ā€œAccept-Encoding: gzipā€.

It would be great if APIGW would support it out of the box and thereā€™s a thread in the forum https://forums.aws.amazon.com/thread.jspa?threadID=192948&tstart=0

Iā€™m a fan of the serverless framework. Weā€™re using it for a large project at work. Still, I have a side project I have been working on for many years. It uses JEE7 and RESTEasy on the back end running in Wildfly server on Openshift Origin. I have some heavyweight endpoints that returned 22 megs of data for some users (a matrix representation of data). I was thinking I needed a massive model rewrite immediately. Then I came across a blog about gzipping json responses. I was able to go from returning 22mb of data from one endpoint down to 1.6mb by adding @GZIP annotation to it. Thatā€™s all I had to do. I came here to see if it was as easy to do something similar with the serverless framework. Apparently not. It seems thereā€™s some magic left in the old Enterprise Java yet.

service: xxxxxxxxxxxxxxx
provider:
name: aws
runtime: python3.7
apiGateway:
minimumCompressionSize: 1024