Gzip not compressing response body with status code other than 200, 403, 404

[Bruno Prémont]

Hello Maxim,

On Sat, 01 September 2012 Maxim Dounin <mdounin at mdounin.ru> wrote:
> On Sat, Aug 25, 2012 at 02:32:02AM -0400, soniclee wrote:
> 
> > I met same problem while try to gzip response with other status code. Any
> > update for this issue?
> 
> In some cases it's just not possible to compress 
> response, e.g. you can't compress 206 as it doesn't contain full 
> entity body.  Or you can't compress 304 as it has no entity at 
> all.
> 
> In many cases it's unwise/unsafe to compress responses with some  
> status codes.  I.e. you probably don't want to compress 400 (Bad 
> Request) response even if client claimed gzip support before it 
> did some syntax error in the request - as you already know client 
> did something wrong, and it's better to return easy to understand 
> response.  Or e.g. if you try to return 500 (Internal Server 
> Error) due to memory allocation error - you probably don't want to 
> allocate memory for gzip.
> 
> Due to the above reasons gzip compression is done only for certain 
> common and safe response codes.  And from the above explanation it 
> should be more or less obvious that it just can't be enabled for 
> all status codes.  
> 
> If you think gzip compression should be enabled for some specific 
> status code - please provide your suggestions with reasoning.

One status code that should allow compression is 410 "Gone", it
is mostly equivalent to 404 just stronger. (patch attached)

Probably most 5xx error pages generated by an upstream should
also be compressed if the request as seen by nginx is valid.
(e.g. a 503 or 500 error returned by upstream, especially when they
are rather large)

Bruno
-------------- next part --------------
A non-text attachment was scrubbed...
Name: nginx-1.2.7-gzip-http410.patch
Type: text/x-patch
Size: 1369 bytes
Desc: not available
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20130303/6ce733aa/attachment.bin>