Default value of gzip_proxied
B.R.
reallfqq-nginx at yahoo.fr
Tue Mar 24 18:11:17 UTC 2015
Hi Maxim,
There is still something I do not get...
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.
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.
'tunnel' is considered different as a 'proxy', as section 2.3
<http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-14#section-2.3>
indicates:
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 mdounin.ru> 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
> http://nginx.org/
>
> _______________________________________________
> nginx mailing list
> nginx at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20150324/51a93811/attachment-0001.html>
More information about the nginx
mailing list