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
Received on Wed Aug 21 2013 - 08:21:17 MDT
This archive was generated by hypermail 2.2.0 : Wed Aug 21 2013 - 12:00:43 MDT