Default value of gzip_proxied

[B.R.]

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
thing?
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 mdounin.ru> 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
> > <http://nginx.org/en/docs/http/ngx_http_gzip_module.html#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
> 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/20150321/06b71446/attachment.html>