Solved: jetty + gzip + heroku returns gzipped data without... - Page 2

Report Inappropriate Content · 05-01-2015 10:56 AM

I have a very basic test app that supports gzip encoding: https://ecd0-hello.herokuapp.com/

I also have a pass-through proxy with no proxies here: http://ecd-test.apigee.net/hello

The result is that my response is gzipped as expected, but the "Content-Encoding: gzip" header is dropped, causing it to be malformed.

I'm not sure what exactly is going on here. It works via Apigee If I don't use heroku, don't enable gzip on the origin, or use tomcat instead of jetty. The origin seems to be working properly in all cases.

Anyone have any hints?

Report Inappropriate Content

Hi Eric,

Yes, your origin is working fine, but we have a known issue for your situation. Here's your response headers.

< HTTP/1.1 200 OK
< Connection: close
< Date: Fri, 01 May 2015 18:21:10 GMT
< Content-Type: application/json;charset=UTF-8
< Content-Encoding: gzip
< Vary: Accept-Encoding, User-Agent
* Server Jetty(9.2.9.v20150224) is not blacklisted
< Server: Jetty(9.2.9.v20150224)
< Via: 1.1 vegur

If you notice, there is no Content-Length or Transfer-Encoding header. You do have a Connection: close header. The HTTP 1.1 spec says this is fine, i.e. "...the transfer-length of the body may be determined by the server closing the connection..." However, we do not handle this situation well at this point in time but we do have this in our backlog to fix.

As a workaround, you could..

Update your back-end to send either the Transfer-Encoding or Content-Length header.
You may be able to add an AssignMessage policy in the response flow that adds the Content-Encoding: gzip header to the response from the proxy (based upon whether the Accept-Encoding header was passed into the proxy by the client).

Hope this helps.

-Dave

View solution in original post

jetty + gzip + heroku returns gzipped data without Content-Encoding header