Rewrite Vary header before stored in proxy_cache
Lucas Rolff
lucas at lucasrolff.com
Mon Oct 24 04:38:25 UTC 2016
Hi guys,
I'm building a small nginx reverse proxy to take care of a bunch of static
files for my clients - and it works great.
One thing I'm facing though is that some client sites sent "Vary:
Accept-Encoding, User-Agent" - which gives an awful cache hit rate - since
proxy_cache takes this into account, unless I use something like
"proxy_ignore_headers Vary;"
But ignoring Vary headers can cause other issues such as gzipped content
being sent to a non-gzip client.
So I'm looking for a way to basically rewrite the vary header to "Vary:
Accept-Encoding" before storing it in proxy_cache - but I wonder if this is
even possible in nginx, and if yes - can you give any pointers?
I found a temporary fix, and that is to ignore the Vary header, and using a
custom variable as a part of the cache key, that is either "", "gzip" or
"deflate" (I use a map to look at the Accept-Encoding header from the
client).
This works great - but I rather keep the cache key a bit clean (since I'll
use it later)
Do you guys have any recommendations how to make this happen?
Also as a side note, if I remove the custom variable from the cache key,
how would one actually purge the file then? I assume I have to send
different purge requests, since the cached file is based on the Vary:
accept-encoding - so I'd have to purge at least the amount of cached
encodings right?
Also I could opt for another way, and that's always requesting a
uncompressed file from the origin (Is it simply not sending the
accept-encoding header, or should I do something else?), and then on every
request either decide to gzip it or not - the downside I see here, is the
fact that most clients request gzip,deflate content, so having to compress
on every request will use additional CPU resources.
Thanks in advance!
--
Best regards,
Lucas Rolff
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20161024/ff8f5f5c/attachment.html>
More information about the nginx
mailing list