Default value of gzip_proxied

Maxim Dounin mdounin at
Sun Mar 22 01:31:17 UTC 2015


On Sat, Mar 21, 2015 at 04:05:05PM +0100, B.R. wrote:

> Hello Maxim,
> So HTTP/1.0 is the reason of all that.
> Now I also understand why there are those parameters allowing to compress
> data that should not be cached: nginx as webserver tries to be smarter than
> those dumb HTTP/1.0 proxies.
> I was wondering, though: are there real numbers to back this compatibility
> thing?
> Is not there a point in time when the horizon could be set, denying
> backwards compatibility for older software/standards?
> HTTP/1.1, is the most used version of the protocol, nginx supports SPDY,
> HTTP/2.0 is coming... and there are strangeness there for
> backwards-compatibility with HTTP/1.0.
> That behavior made us cache uncompressed content 'randomly' since the
> pattern was hard to find/reproduce, and I got a bit of luck determining the
> condition under which we were caching uncompressed data...
> What is the ratio benefits/costs of dropping compatibility (at least
> partially) with HTTP/1.0?
> I know I am being naive here, considering the most part of the Web is
> HTTP/1.1-compliant, but how far am I for reality?

There are two problems:

- You assume HTTP/1.0 is dying.  That's not true.  While uncommon 
  nowadays for browsers, it's still widely used by various 
  software.  In particular, nginx itself use it by default when 
  talking to upstream servers.

- You assume that the behaviour in question is only needed for 
  HTTP/1.0 clients.  That's, again, not true, as using "Vary: Accept-Encoding" 
  isn't a good idea either.  As already mentioned, even if 
  correctly supported it will cause cache data duplication.

If you don't like the behaviour, you can always configure nginx to 
do whatever you want.  But I don't think the default worth 

Maxim Dounin

More information about the nginx mailing list