<div dir="ltr"><div class="gmail_default" style="font-size:small;color:rgb(51,51,153)">Hello Maxim,<br><br></div><div class="gmail_default" style="font-size:small;color:rgb(51,51,153)">So HTTP/1.0 is the reason of all that.<br></div><div class="gmail_default" style="font-size:small;color:rgb(51,51,153)">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.<br><br></div><div class="gmail_default" style="font-size:small;color:rgb(51,51,153)">I was wondering, though: are there real numbers to back this compatibility thing?<br></div><div class="gmail_default" style="font-size:small;color:rgb(51,51,153)">Is not there a point in time when the horizon could be set, denying backwards compatibility for older software/standards?<br><br></div><div class="gmail_default" style="font-size:small;color:rgb(51,51,153)">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.<br></div><div class="gmail_default" style="font-size:small;color:rgb(51,51,153)">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...<br><br></div><div class="gmail_default" style="font-size:small;color:rgb(51,51,153)">What is the ratio benefits/costs of dropping compatibility (at least partially) with HTTP/1.0?<br></div><div class="gmail_extra">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?<br clear="all"><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 Sat, Mar 21, 2015 at 3:21 PM, 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 Fri, Mar 20, 2015 at 07:41:59PM +0100, B.R. wrote:<br>
<br>
> I recently bumped into some trouble with a client caching uncompressed data<br>
> without understanding where it came from.<br>
><br>
> After long investigation on what appeared to be random, I narrowed it to<br>
> the gzip_proxied<br>
</span>> <<a href="http://nginx.org/en/docs/http/ngx_http_gzip_module.html#gzip_proxied" target="_blank">http://nginx.org/en/docs/http/ngx_http_gzip_module.html#gzip_proxied</a>><br>
> directive. Return content from webserver was supposed to be *always*<br>
<span class="">> compressed (as compressed data is generally better than uncompressed<br>
> whenever possible), but when requests coming from clients behind proxies<br>
> resulted in MISS, the returned content was uncompressed and stored as such<br>
> in cache... thus serving cached uncompressed data to final clients.<br>
><br>
> ​Why is the default value of that directive 'off'? What is the problem with<br>
> sneding compressed data to proxies? Why have you decided on such a default<br>
> value?<br>
<br>
</span>Because not all clients support compression, and it's not possible<br>
to instruct HTTP/1.0 proxies to serve compressed version only to<br>
some clients.  In HTTP/1.1 there is a Vary header for this, but<br>
nevertheless it's usually bad idea to use it as it causes huge<br>
cache duplication.<br>
<span class="HOEnZb"><font color="#888888"><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></font></span></blockquote></div><br></div></div>