Ver interesting, Maxim.

I was wondering if this works with proxy_cache... will it unzip
compressed responses from cache?

If so, it would make a lot of sense to write something that would
compress items *before* putting them into cache, even if the backend
has not compressed them. And we could use a high compress-level if the
item is cachable. Since 95% of clients support gzip, this would seem
to be the ideal way to run an HTTP proxy (compression is done once per
stored object, and decompressed on the fly if necessary for a
particular client).

Any thoughts on that? Would an additional proxy_cache_gzip module be a
good idea, or would it have to be a patch to the main proxy_cache
module?

I suppose something similar could be done right now by having an extra
proxy layer (a "fetcher/compressor" layer) behind the cache, but that
seems like a hack.

On Mon, Mar 22, 2010 at 1:20 PM, Maxim Dounin <mdounin@mdounin.ru> wrote:
> Hello!
>
> Changes with gunzip module 0.3 (2010-03-22):
>
>    *) Bugfix: the "[alert] zero size buf" error during gunzipping of
>       some files.
>       Thanks to Matthieu Tourne.
>
>    *) Bugfix: incorrect code was used for nginx 0.8.0 .. 0.8.24.  The bug
>       had appeared in gunzip module 0.2.
>
> Repository is available here:
>
> http://mdounin.ru/hg/ngx_http_gunzip_filter_module/
>
> Source tarball may be obtained here:
>
> http://mdounin.ru/files/ngx_http_gunzip_filter_module-0.3.tar.gz
>
> MD5 (ngx_http_gunzip_filter_module-0.3.tar.gz) = 32bb38f341786b042009e236c59cf1cc
> SHA256 (ngx_http_gunzip_filter_module-0.3.tar.gz) = c1860befc868970dce4085631e7717c749329883d8b05a2a64bd2850f346cd39
>
> Maxim Dounin
>
> _______________________________________________
> nginx mailing list
> nginx@nginx.org
> http://nginx.org/mailman/listinfo/nginx
>



--
RPM

_______________________________________________
nginx mailing list
nginx@nginx.org
http://nginx.org/mailman/listinfo/nginx