Default value of gzip_proxied

B.R. reallfqq-nginx at yahoo.fr
Tue Mar 24 22:59:24 UTC 2015


Hi,
​

> > 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?​


> > 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.

​What is it I do not get?
---
*B. R.*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20150324/8b00ae85/attachment-0001.html>


More information about the nginx mailing list