Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP

Loading…

Save gzip and normal version #11

Open
ricardovf opened this Issue · 8 comments

3 participants

@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
Owner
@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
Owner
@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
Owner
@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
Owner

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.