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