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 support
Posted
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.
Posted at Nginx Forum:
https://forum.nginx.org/read.php?2,270604,270665#msg-270665
Hello,
It's not strange behavior, it's expected.
What happens is that even though the key is the same - the actual
returned content *might* be different, e.g. as an example:
If your origin returns Vary: accept-encoding
Nginx will cache based on this - so if accept-encoding differs it means
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
Well - then put fastcgi_ignore_headers Vary, make your map determine if
the client support gzip or not, then you'll have 2 entries of
everything, 1 gzipped and one not gzipped.
I'm not sure how much traffic we're talking about when it's about 'high
traffic' - you'd probably want to run your
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%).
What you could do (I basically asked the same question 1 week ago), is
that whenever you fastcgi_pass then enforce accept-encoding: gzip -
meaning you'll always request gzipped content from your backend - then
you can enable the gunzip directive by using "gunzip on;"
This means in case a
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.
$http_accept_encoding gets the value of the HTTP Accept-Encoding header.
This might vary depending on the client being used, unless you control them
and their value.
Thus, the same request being made with a different (set of) value(s) in
this header will generate another key.
If you simply want
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
10 matches
Mail list logo
