ring-gzip-middleware icon indicating copy to clipboard operation
ring-gzip-middleware copied to clipboard

Setting Content Length on GZip Requests

Open gja opened this issue 9 years ago • 4 comments
trafficstars

This adds a Content-Length to the response, if an original Content-Length was present, and less than 1MB. This prevents jetty from adding Transfer-Encoding: chunked to the response, without requiring Connection: Close

gja avatar Oct 28 '16 11:10 gja

Hello Maintainers,

Do you have any feedback on this pull request?

gja avatar Nov 07 '16 05:11 gja

Hi there, this looks like it could be a good patch to include, are you able to add any tests? I realise it's been a long time since the original PR, so can understand if you've moved on. Also, this behaviour seems like it should be configurable somehow, as people may not want to create the byte-array. What are the implications of the current behaviour?

This prevents jetty from adding Transfer-Encoding: chunked to the response, without requiring Connection: Close

Can you expand on what the issues with this are?

danielcompton avatar Dec 06 '18 07:12 danielcompton

Let me check. I know that we rely on this behaviour, but I can't remember what are the reasons are. IIRC, it was that some proxies were refusing to cache the response, as it believed that it was receiving a stream, or something like that.

gja avatar Dec 06 '18 09:12 gja

I took a sensible default of only buffering responses up to 1mb in memory. This should cover most HTML responses and API responses, while only consuming < 1mb of memory. I doubt anyone will serve files more than 1 mb from ring.

gja avatar Dec 06 '18 09:12 gja