Default value of gzip_proxied

B.R. reallfqq-nginx at
Sat Mar 21 15:05:05 UTC 2015

Hello Maxim,

So HTTP/1.0 is the reason of all that.
Now I also understand why there are those parameters allowing to compress
data that should not be cached: nginx as webserver tries to be smarter than
those dumb HTTP/1.0 proxies.

I was wondering, though: are there real numbers to back this compatibility
Is not there a point in time when the horizon could be set, denying
backwards compatibility for older software/standards?

HTTP/1.1, is the most used version of the protocol, nginx supports SPDY,
HTTP/2.0 is coming... and there are strangeness there for
backwards-compatibility with HTTP/1.0.
That behavior made us cache uncompressed content 'randomly' since the
pattern was hard to find/reproduce, and I got a bit of luck determining the
condition under which we were caching uncompressed data...

What is the ratio benefits/costs of dropping compatibility (at least
partially) with HTTP/1.0?
I know I am being naive here, considering the most part of the Web is
HTTP/1.1-compliant, but how far am I for reality?
*B. R.*

On Sat, Mar 21, 2015 at 3:21 PM, Maxim Dounin <mdounin at> wrote:

> Hello!
> On Fri, Mar 20, 2015 at 07:41:59PM +0100, B.R. wrote:
> > I recently bumped into some trouble with a client caching uncompressed
> data
> > without understanding where it came from.
> >
> > After long investigation on what appeared to be random, I narrowed it to
> > the gzip_proxied
> > <>
> > directive. Return content from webserver was supposed to be *always*
> > compressed (as compressed data is generally better than uncompressed
> > whenever possible), but when requests coming from clients behind proxies
> > resulted in MISS, the returned content was uncompressed and stored as
> such
> > in cache... thus serving cached uncompressed data to final clients.
> >
> > ​Why is the default value of that directive 'off'? What is the problem
> with
> > sneding compressed data to proxies? Why have you decided on such a
> default
> > value?
> Because not all clients support compression, and it's not possible
> to instruct HTTP/1.0 proxies to serve compressed version only to
> some clients.  In HTTP/1.1 there is a Vary header for this, but
> nevertheless it's usually bad idea to use it as it causes huge
> cache duplication.
> --
> Maxim Dounin
> _______________________________________________
> nginx mailing list
> nginx at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the nginx mailing list