Just for the record: this topic contains 2 suggested solutions: 1) storing gzip compressed and uncompressed HTML separately and have Nginx determine gzip support instead of the client 2) storing gzip permanently and use Nginx gunzip module to gunzip HTML for browsers without gzip supportby seo010 - Nginx Mailing List - English
Hi Lucas, Thanks a lot for the information! Hopefully it will help many others that find the topic via Google as there was almost no information about it available.by seo010 - Nginx Mailing List - English
Hi Lucas, Thanks a lot for the suggestion. We were already using that solution but a strange behavior occurred (see opening post). The first request uses an expected MD5 hash of the KEY, and the client will keep using that hash (the MISS/HIT header is accurate). However, requests from other clients will make Nginx use a different (unknown) MD5 hash for the exact same content and KEY. The cacheby seo010 - Nginx Mailing List - English
Hi! It sounds like a good solution to improve the performance, however, I just read the following post by Jake Archibald (Google Chrome developer). "Yeah, ~10% of BBC visitors don’t support gzip compression. It was higher during the day (15-20%) but lower in the evenings and weekends (<10%). Pretty much puts the blame in the direction of corporate proxies." https://www.stevby seo010 - Nginx Mailing List - English
Hi *B. R.*! Thanks a lot for the reply and information! The KEY however, does not contain different data from http_accept_encoding. When viewing the contents of the cache file it contains the exact same KEY for both MD5 hashes. Also, it does not matter what browser is used for the first request. For example, using a Google PageSpeed test at the first request will create the expected MD5 hash foby seo010 - Nginx Mailing List - English
Hi! I was wondering if anyone has an idea to serve pre-compressed (gzip) HTML using proxy_cache / fastcgi_cache. I tried a solution with a map of http_accept_encoding as part of the fastcgi_cache_key with gzip compressed output from the script, but it resulted into strange behavior (the MD5 hash for the first request corresponds to the KEY, the next requests with an unknown MD5 hash using thby seo010 - Nginx Mailing List - English