On 21/08/2013 12:00 a.m., jabourbih wrote:
Using Squid in an accelerator (reverse proxy) configuration, I'd like to
normalize the user-agent and accept-encoding headers *before* Squid
generates its cache key.
In other words, I want to ensure that Squid does not cache different
responses for different browsers and/or different orders of acceptable
encodings (e.g. Chrome sends gzip,deflate,sdch, whereas Firefox sends
gzip,deflate; I want to cache only one response). If the upstream server
responds with a Vary: Accept-Encoding, it would cache two responses, which
is not the desired behaviour.
Yes this is the desired behaviour. The order of the entries in
Accept-Encoding list the order of preference. If the server is properly
obeying that preference order you will get two different responses to
"Accept-Encoding: gzip, deflate" and "Accept-Encoding: deflate, gzip".
I've looked at request_header_access and request_header_replace, but the
docs say "The option has no effect during cache hit detection."
Yes, they are alteration of the outgoing request to server which is done
just before sending.
Is there any way to rewrite the headers so that if gzip is in the
Accept-Encoding header, then the header is rewritten to only contain gzip,
and have Squid use the rewritten header as part of its cache key, rather
than the original request header?
You can mangle the request with eCAP or ICAP.
There is also a "Key:" header being spec'd out in the IETF and being
considered for future Squid use. If you are interested in helping with
that I am looking for asistance.
Amos
