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 <mdounin@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
