<div dir="ltr"><div class="gmail_default" style="font-size:small;color:rgb(51,51,153)">I do not get why you focus on the gzip_vary directive, while I was explicitely talking about gzip_proxied.<br></div><div class="gmail_default" style="font-size:small;color:rgb(51,51,153)">The fact that content supposedly compressed might actually not be because it contains a 'Via' header is the root cause of our trouble... and you just told me it was for HTTP/1.0 compatibility.<br></div><div class="gmail_default" style="font-size:small;color:rgb(51,51,153)">This behavior, put aside the HTTP/1.0 compatibility, is strange and disruptive at best.<br></div><div class="gmail_default" style="font-size:small;color:rgb(51,51,153)"><br></div><div class="gmail_default" style="font-size:small;color:rgb(51,51,153)">I willingly join you on the fact that still a lot of software uses HTTP/1.0, but I usually distinguish that from the reasons behind it and what it should be.<br></div><div class="gmail_default" style="font-size:small;color:rgb(51,51,153)">I assume nginx defaults to talking HTTP/1.0 with backend because it is the lowest common denominator. That allows to handle outdated software and I can understand that when you wish to be universal.<br></div><div class="gmail_default" style="font-size:small;color:rgb(51,51,153)"><br></div><div class="gmail_default" style="font-size:small;color:rgb(51,51,153)">nginx seems to be stuck not knowing which way the wind is blowing, sometimes promoting modernity and sometimes enforcing backwards (yes, HTTP/1.0 means looking backwards) compatibility.<br></div><div class="gmail_extra"><div class="gmail_default" style="font-size:small;color:rgb(51,51,153)">​While setting default values to be interoperable the most, which I understand perfectly, ​there should be somewhere bright pointers about the fact that some directives only exists for such reasons. I would be more than welcoming that defualt configuration introduces commented examples about what modern configuration/usage of nginx shall be.<br></div><div class="gmail_default" style="font-size:small;color:rgb(51,51,153)"><br>'gzip on' clearly is clearly not enough if you want to send compressed content. How much people know about it? 'RTFM' stance is no longer valid when multiple directives shall be activated at once on a modern infrastructure. nginx configuration was supposed to be lean and clean. It is, provided that you use outdate protocol to serve content: minimal configuration for compatibility is smaller than the one for modern protocols... and you need to dig by yourself to learn that. WTF?<br></div><div><div class="gmail_signature"><font size="1"><span style="color:rgb(102,102,102)">---<br></span><b><span style="color:rgb(102,102,102)">B. R.</span></b><span style="color:rgb(102,102,102)"></span></font></div></div>
<br><div class="gmail_quote">On Sun, Mar 22, 2015 at 2:31 AM, Maxim Dounin <span dir="ltr"><<a href="mailto:mdounin@mdounin.ru" target="_blank">mdounin@mdounin.ru</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello!<br>
<span class=""><br>
On Sat, Mar 21, 2015 at 04:05:05PM +0100, B.R. wrote:<br>
<br>
> Hello Maxim,<br>
><br>
> So HTTP/1.0 is the reason of all that.<br>
> Now I also understand why there are those parameters allowing to compress<br>
> data that should not be cached: nginx as webserver tries to be smarter than<br>
> those dumb HTTP/1.0 proxies.<br>
><br>
> I was wondering, though: are there real numbers to back this compatibility<br>
> thing?<br>
> Is not there a point in time when the horizon could be set, denying<br>
> backwards compatibility for older software/standards?<br>
><br>
> HTTP/1.1, is the most used version of the protocol, nginx supports SPDY,<br>
> HTTP/2.0 is coming... and there are strangeness there for<br>
> backwards-compatibility with HTTP/1.0.<br>
> That behavior made us cache uncompressed content 'randomly' since the<br>
> pattern was hard to find/reproduce, and I got a bit of luck determining the<br>
> condition under which we were caching uncompressed data...<br>
><br>
> What is the ratio benefits/costs of dropping compatibility (at least<br>
> partially) with HTTP/1.0?<br>
> I know I am being naive here, considering the most part of the Web is<br>
> HTTP/1.1-compliant, but how far am I for reality?<br>
<br>
</span>There are two problems:<br>
<br>
- You assume HTTP/1.0 is dying.  That's not true.  While uncommon<br>
  nowadays for browsers, it's still widely used by various<br>
  software.  In particular, nginx itself use it by default when<br>
  talking to upstream servers.<br>
<br>
- You assume that the behaviour in question is only needed for<br>
  HTTP/1.0 clients.  That's, again, not true, as using "Vary: Accept-Encoding"<br>
  isn't a good idea either.  As already mentioned, even if<br>
  correctly supported it will cause cache data duplication.<br>
<br>
If you don't like the behaviour, you can always configure nginx to<br>
do whatever you want.  But I don't think the default worth<br>
changing.<br>
<div class="HOEnZb"><div class="h5"><br>
--<br>
Maxim Dounin<br>
<a href="http://nginx.org/" target="_blank">http://nginx.org/</a><br>
<br>
_______________________________________________<br>
nginx mailing list<br>
<a href="mailto:nginx@nginx.org">nginx@nginx.org</a><br>
<a href="http://mailman.nginx.org/mailman/listinfo/nginx" target="_blank">http://mailman.nginx.org/mailman/listinfo/nginx</a><br>
</div></div></blockquote></div><br></div></div>