Default value of gzip_proxied

B.R. reallfqq-nginx at
Tue Mar 24 18:11:17 UTC 2015

Hi Maxim,

There is still something I do not get...

The 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.
However, the 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.


   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

'tunnel' is considered different as a 'proxy', as section 2.3

   There are three common forms of HTTP
   intermediary: proxy, gateway, and tunnel.

Thus, any HTTP/1.0 proxy should be seen with a HTTP/1.0 protocol version
header... and thus should naturally get an uncompressed version of the page.

Non-compliant proxies can be bogus in thousands of way, so there is no
point in trying to satisfy them anyway.

In the light of these elements, I am still wondering why the default
behavior of the gzip module for HTTP/1.1 requests going through a
(HTTP/1.1) proxy is to send a disturbing uncompressed version of the page.
*B. R.*

On Sun, Mar 22, 2015 at 6:06 PM, Maxim Dounin <mdounin at> wrote:

> Hello!
> On Sun, Mar 22, 2015 at 03:14:22PM +0100, B.R. wrote:
> > I do not get why you focus on the gzip_vary directive, while I was
> > explicitely talking about gzip_proxied.
> > The fact that content supposedly compressed might actually not be because
> > it contains a 'Via' header is the root cause of our trouble... and you
> just
> > told me it was for HTTP/1.0 compatibility.
> With HTTP/1.0, there is only one safe option:
> - don't compress anything for proxies.
> With HTTP/1.1, there are two options:
> - don't compress anything for proxies;
> - compress for proxies, but send Vary to avoid incorrect behaviour.
> The second options, which becomes available if you don't care
> about HTTP/1.0 compatibility at all, has its downsides I've
> talked about.
> --
> Maxim Dounin
> _______________________________________________
> nginx mailing list
> nginx at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the nginx mailing list