Default value of gzip_proxied
mdounin at mdounin.ru
Wed Mar 25 21:36:55 UTC 2015
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
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,
Due to interoperability problems with HTTP/1.0 proxies discovered
since the publication of RFC 2068, caching proxies MUST, gateways
MAY, and tunnels MUST NOT upgrade the request to the highest version
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.
More information about the nginx