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 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
then srcache would use that info.
Great work so far, im really glad! =)
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!
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?
@normanjoyner I'd suggest the following options:
proxy_set_header Accept-Encoding '';
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).
Awesome! I appreciate the help.