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 <mdou...@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@nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx
_______________________________________________ nginx mailing list nginx@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx
