Default value of gzip_proxied
Maxim Dounin
mdounin at mdounin.ru
Sun Mar 22 01:31:17 UTC 2015
Hello!
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
changing.
--
Maxim Dounin
http://nginx.org/
More information about the nginx
mailing list