<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)">Thanks for having taken the time of explaining it all!<br></div><div class="gmail_default" style="font-size:small;color:rgb(51,51,153)">It seems HTTP/1.0 interoperability is seriously flawed...<br><br></div><div class="gmail_default" style="font-size:small;color:rgb(51,51,153)">Anyhow, now I understand nginx' default behavior, which makes sense.<br></div><div class="gmail_extra"><div class="gmail_default" style="font-size:small;color:rgb(51,51,153)">​Our needs are very specific, since nginx is hidden behind an internal cache, but the general case, real front-end, is safe. :o)​<br><br></div><div class="gmail_default" style="font-size:small;color:rgb(51,51,153)">Thanks again,<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 Wed, Mar 25, 2015 at 10:36 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 Tue, Mar 24, 2015 at 11:59:24PM +0100, B.R. wrote:<br>
<br>
> > > The gzip_proxied<br>
> > > <<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>
> > > default value is set to honor the HTTP/1.0 protocol (which does not have<br>
> > > the Vary header and thus is unable to cache different versions of a<br>
> > > document) in some proxies.<br>
> ><br>
> > You are still misunderstanding things.  It's one of the two<br>
> > possible approaches to handle things even if we forget about<br>
> > HTTP/1.0 completely.<br>
> ><br>
><br>
> ​Well the 2 only possible approaches in 1.0 are to send compressed or<br>
> uncompressed data.<br>
> Client supporting compressed version​<br>
><br>
> ​will understand the uncompressed one but the reverse might not be true.<br>
> So if you are not able to make the answer being served from cache to vary<br>
> (which is the case in 1.0), you are actually stuck with a single option,<br>
> the only common denominator: no compression at all. Right?​<br>
<br>
</span>Yes, the only option if we care about HTTP/1.0 is to avoid<br>
compression for proxies.<br>
<div><div class="h5"><br>
> > > However, the gzip_http_version<br>
> > > <<br>
> > <a href="http://nginx.org/en/docs/http/ngx_http_gzip_module.html#gzip_http_version" target="_blank">http://nginx.org/en/docs/http/ngx_http_gzip_module.html#gzip_http_version</a>><br>
> > > default value is set so that only HTTP/1.1 requests are being<br>
> > compressed...<br>
> > > Thus with the default setting it is impossible to compress requests<br>
> > > advertising HTTP/1.0.<br>
> > ><br>
> > > The RFC<br>
> > > <<br>
> > <a href="http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-14#section-2.5" target="_blank">http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-14#section-2.5</a>><br>
> > > dictates:<br>
> > ><br>
> > >    Intermediaries that process HTTP messages (i.e., all intermediaries<br>
> > >    other than those acting as a tunnel) MUST send their own HTTP-Version<br>
> > >    in forwarded messages.  In other words, they MUST NOT blindly forward<br>
> > >    the first line of an HTTP message without ensuring that the protocol<br>
> > >    version matches what the intermediary understands, and is at least<br>
> > >    conditionally compliant to, for both the receiving and sending of<br>
> > >    messages.<br>
> ><br>
> > As you can see from the paragraph you quoted, nginx only knows<br>
> > HTTP version of the intermediary it got the request from.  That<br>
> > is, there is no guarantee that there are no HTTP/1.0 proxies along<br>
> > the request/response chain.<br>
> ><br>
><br>
> ​The text I quoted means than at the end of a chain of intermediaries, you<br>
> are ensured that you will end up with the greatest common denominator, ie<br>
> if a single element of the intermediaries chain does not handle 1.1, he his<br>
> required to forward the request with a 1.0 version header, which will then<br>
> be left untouched by following intermediaries (as 1.0 is the smallest<br>
> version available)​.<br>
> An intermediary seing a 1.1 request coming in but not supporting that<br>
> version is required to step down to a version it understands, meaning 1.0.<br>
> It should not forward 1.1.<br>
><br>
> If nginx sees 1.1 coming, it is my understanding that every intermediary<br>
</div></div>> supports *at least* 1.1, whatever number of intermediaries we are talking<br>
> about.<br>
<br>
No.  The text ensures that nginx will see HTTP/1.0 if the last<br>
proxy doesn't understand HTTP/1.1.  There is no requirement to<br>
preserve supported versions untouched.  Moreover, first sentence<br>
requires intermediaries to use their _own_ version.  And RFC2616<br>
explicitly requires the same,<br>
<a href="http://tools.ietf.org/html/rfc2616#section-3.1" target="_blank">http://tools.ietf.org/html/rfc2616#section-3.1</a>:<br>
<br>
   Due to interoperability problems with HTTP/1.0 proxies discovered<br>
   since the publication of RFC 2068[33], caching proxies MUST, gateways<br>
   MAY, and tunnels MUST NOT upgrade the request to the highest version<br>
   they support.<br>
<br>
That is, in a request/response chain like this:<br>
<br>
    client -> proxy1 -> proxy2 -> nginx<br>
<br>
If proxy1 supports only HTTP/1.0, but proxy2 supports HTTP/1.1,<br>
nginx will see an HTTP/1.1 request.<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></div></div></blockquote></div><br></div></div>