Default value of gzip_proxied

[Maxim Dounin]

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/