Save gzip and normal version

[ricardovf]

Hi!

FIrst of all, really GREAT work. Im using it with our js/css packer and it is working really great cause the URLs are hashed so I can store the requests on memcached forever and all automatically. With just memc module i was having to write the assets to memcached in the application backend and i did not like it.

In your TODO it is written Gzip. So i would like to see if it checks with what i would like:

Now im using Nginx Gzip Module to gzip css/js/html on the fly, after it comes from srcache or backend. If srcache could save a gzip version of the content it could be served directlly. What doesnt go in srcache would still be gzipped on the fly.

Not that it is necessary to save a not gzipped version to save IE6. You could even read the gzip_disable var.

Is that the way you are thinking?

Thx and keep the great work!

[agentzh]

On Thu, Jan 12, 2012 at 3:08 AM, Ricardo Fritsche
reply@reply.github.com
wrote:

Hi!

FIrst of all, really GREAT work. Im using it with our js/css packer and it is working really great cause the URLs are hashed so I can store the requests on memcached forever and all automatically. With just memc module i was having to write the assets to memcached in the application backend and i did not like it.

Glad you like it :)

In your TODO it is written Gzip. So i would like to see if it checks with what i would like:

Now im using Nginx Gzip Module to gzip css/js/html on the fly, after it comes from srcache or backend. If srcache could save a gzip version of the content it could be served directlly. What doesnt go in srcache would still be gzipped on the fly.

Not that it is necessary to save a not gzipped version to save IE6. You could even read the gzip_disable var.

Well, the main purpose of the gzip compression support is to save
storage on the memcached level instead of saving CPU cycles, so
uncompressed version of the data will not be stored separately because
that'll just increase the total storage used in memcached. To simplify
things here, I'd always compress the response in the srcache_fetch
phase, and uncompress the data in the srcache_store phase only on
need. That is, if the curent request indicates that the client accepts
the gzip content encoding, then the compressed data from memcached
will be directly served out, otherwise, ngx_srcache will uncompress
the data.

Does it look sane to you?
-agentzh

Is that the way you are thinking?

Thx and keep the great work!

---

Reply to this email directly or view it on GitHub:
#11

[ricardovf]

@agentzh It looks perfect cause only a small amount of clients would need descompression as IE6 is going down quickly.

The only thing i would like to ask is that you make it work with the current gzip_ options so we do not need to rewrite stuff. So if i have

     gzip_types       application/xml application/x-javascript text/css;

then srcache would use that info.

Great work so far, im really glad! =)

[agentzh]

On Sun, Jan 15, 2012 at 12:52 AM, Ricardo Fritsche
reply@reply.github.com
wrote:

@agentzh It looks perfect cause only a small amount of clients would need descompression as IE6 is going down quickly.

The only think i would like to ask is that you make it work with the current gzip_ options so we do not need to rewrite stuff. So if i have

        gzip_types       application/xml application/x-javascript text/css;

then srcache would use that info.

Oh, it may be difficult and unsafe to reuse the config stuffs in
ngx_gzip due to encapsulation of individual nginx modules. I'm not so
sure here.

Regards,
-agentzh

[ricardovf]

I understand. If there is this limitation, no problem to redefine it again in srcache.

Please let me know if you implement this feature. I will be glad to test when it is ready!

Keep the great work!

[agentzh]

On Mon, Jan 16, 2012 at 6:48 PM, Ricardo Fritsche
reply@reply.github.com
wrote:

I understand. If there is this limitation, no problem to redefine it again in srcache.

Please let me know if you implement this feature. I will be glad to test when it is ready!

I will. Thank you in advance :)

Best regards,
-agentzh

[normanjoyner]

Hey, I was curious of the current status of this. If gzip compression is turned on in nginx, how will srcache handle caching / serving responses? If the gzipped data is cached, is there a way to automatically gunzip on the fly to clients who cannot handle gzipped content?

[agentzh]

@normanjoyner I'd suggest the following options:

1. Cache both compressed and uncompressed responses, and add (a canonical-ized) value of the Accept-Encoding to your cache key. So that clients which do not expect gzip'd responses result in a cache miss (and trigger caching the uncompressed version).
2. Cache compressed responses and use the standard ngx_gunzip module to uncompress the response body for those clients which do not accept gzip encoding:. See http://nginx.org/en/docs/http/ngx_http_gunzip_module.html But you need to be careful about nginx output filter order (between ngx_srcache's filter and ngx_gunzip's filter).
3. Only cache uncompressed content and rely on the ngx_gzip module to compress the data for those clients expecting gzip. Set proxy_set_header Accept-Encoding ''; for example if the proxy module is used as the content handler.

Note that it has never been an issue if you just turn on gzip in your nginx server. What really matters here is whether to turn on gzip on your backend server (if you're doing proxy in your nginx).

[normanjoyner]

Awesome! I appreciate the help.

[SeanHayes]

I'd like to do option #2, storing gzip compressed content before store and using gunzip after fetch if needed. Is this possible yet?