Pre-compressed (gzip) HTML using fastcgi_cache?

Lucas Rolff lucas at
Mon Oct 31 19:45:23 UTC 2016


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 
the md5 (the path) will be different

So if your cache_key is $host$request_uri, if I request using a standard curl, my accept-encoding 
won't be there, file will be cached under hash XXXXXXXXXXXXXXXXXXXXX 
whenever a Google Chrome user comes along, do the exact same request to the cache_key will still be the same, but 
since chrome sends gzip, deflate (and some other), nginx will still 
cache it differently, thus resulting in different md5's on the filesystem.

If you use fastcgi_ignore_headers Vary; (I don't see this in the initial 
post), it shouldn't generate multiple md5's for the same key.

Basically nginx cache wants to work as it should and actually obey the 
vary header, if you don't want to obey it, you should ignore it. And use 
some other (like gzip_enabled variable) within your cache key to still 
generate 2 different files.

Best Regards,
Lucas Rolff

seo010 wrote:
> 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 cache file contains a row with "KEY: ..." that matches the expected KEY
> and KEY for other MD5 hashes.
> Do you have an idea what may cause this behavior?
> Best Regards,
> Jan Jaap
> Posted at Nginx Forum:,270604,270661#msg-270661
> _______________________________________________
> nginx mailing list
> nginx at

More information about the nginx mailing list