Default value of gzip_proxied
reallfqq-nginx at yahoo.fr
Sat Mar 21 15:05:05 UTC 2015
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?
On Sat, Mar 21, 2015 at 3:21 PM, Maxim Dounin <mdounin at mdounin.ru> wrote:
> On Fri, Mar 20, 2015 at 07:41:59PM +0100, B.R. wrote:
> > I recently bumped into some trouble with a client caching uncompressed
> > 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
> > in cache... thus serving cached uncompressed data to final clients.
> > Why is the default value of that directive 'off'? What is the problem
> > sneding compressed data to proxies? Why have you decided on such a
> > 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 nginx.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the nginx