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

Hello,

I have a WebDAV application setup with nginx in front of application 
server
for reverse proxying. My application returns 207 as status code and I 
found
that nginx does not compress response body with gzip other than 200, 403 
and
404 status. Is there any reason behind this?

Regards,
Tony

I met same problem while try to gzip response with other status code. 
Any
update for this issue?

Posted at Nginx Forum: 
http://forum.nginx.org/read.php?2,203569,230115#msg-230115

Hello!

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.

Maxim Dounin

Hello Maxim,

On Sat, 01 September 2012 Maxim Dounin <mdounin@mdounin.ru> wrote:
> In many cases it's unwise/unsafe to compress responses with some
> 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

Hello!

On Sun, Mar 03, 2013 at 04:07:50PM +0100, Bruno Prémont wrote:

> > entity body.  Or you can't compress 304 as it has no entity at
> >
> > 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)

Any specific reason to?  410 is rarely used at all, and I don't
think we should treat it as a common response code which is safe to
compress.

> 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)

With errors, especially 5xx, you never know what actually went
wrong, and what will happen due to compression applied.  It's
always safer to respond with what we get from an upstream with
minimal modifications.

--
Maxim Dounin
http://nginx.org/en/donation.html