Pre-compressed (gzip) HTML using fastcgi_cache?
lucas at lucasrolff.com
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
http://domain.com/text.html 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
http://domain.com/text.html 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.
> 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: https://forum.nginx.org/read.php?2,270604,270661#msg-270661
> nginx mailing list
> nginx at nginx.org
More information about the nginx