Hello!
On Sun, Mar 03, 2013 at 04:07:50PM +0100, Bruno Prémont wrote:
> Hello Maxim,
>
> On Sat, 01 September 2012 Maxim Dounin <mdounin@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)
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
_______________________________________________
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx
