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
