|Maxim Dounin||Mar 22, 2010 11:20 am|
|Ryan Malayter||Mar 23, 2010 6:12 am|
|Maxim Dounin||Mar 23, 2010 6:46 am|
|Ryan Malayter||Mar 24, 2010 5:47 am|
|Maxim Dounin||Mar 24, 2010 7:20 am|
|Ryan Malayter||Mar 24, 2010 3:49 pm|
|Maxim Dounin||Mar 24, 2010 4:47 pm|
|theromis1||Apr 16, 2010 12:14 pm|
|Maxim Dounin||Apr 17, 2010 2:36 am|
|theromis1||Apr 19, 2010 2:14 pm|
|Maxim Dounin||Apr 19, 2010 7:15 pm|
|theromis1||Apr 20, 2010 4:00 pm|
|Maxim Dounin||Apr 21, 2010 8:19 pm|
|theromis1||Apr 22, 2010 6:35 pm|
|theromis1||Apr 27, 2010 3:29 pm|
|theromis1||May 3, 2010 10:31 am|
|Subject:||Re: [ANNOUNCE] gunzip filter module 0.3|
|From:||Ryan Malayter (mala...@gmail.com)|
|Date:||Mar 24, 2010 5:47:50 am|
On Tue, Mar 23, 2010 at 8:46 AM, Maxim Dounin <mdou...@mdounin.ru> wrote:
I belive proxy_cache must cache response as it was got from upstream. It is not it's business to compress or change anything, there are output filters to do changes.
Transformation of content by proxies and caches is specifically allowed in the HTTP specs, unless a "Cache-Control: no-transform" directive is present.
Or were you referring to the nginx architecture/code specifically? If that is so, why is it not the business of proxy_cache to transform content (it already manipulates headers out of necessity)? Re-applying the same output filter repeatedly is wasteful and increases latency. If Igor is worried about the impact updating HTTP date strings more than once per second, surely avoiding thousands of loops through a gzip filter is an optimization that would be smiled upon?
Even Microsoft gets this specific part right (static content is cached in its compressed state in IIS, and can use a different compression ratio from dynamic content).
On the other hand it is believed to be good idea to implement cache support in gzip filter. I.e. gzip filter will cache gzipped content and will send it to client instead of re-compressing it. And it's actually in Igor's plans AFAIK, but most likely not near plans.
Integrating the compression with the "retrieval" portion of the cache code would allow for the use of high compression ratios for long-lived objects, as well as prevent duplication of data on disk. Also, any caching mechanism is going to need the same quantity of settings and infrastructure as proxy_cache already has, so there would be a lot of unnecessary code duplication if the mechanism was separate from proxy_cache. But it would be more general (for nginx) to have a separate standalone gzip_cache module.