On 22/01/11 11:43, Jonathan Wolfe wrote:
With squid (3.1.8 - .10) in reverse-proxy mode running an eCAP
adapter (gzip), does squid still pull the body to be gzipped from its
cache? I'm setting Vary: Accept-Encoding, and seeing HITs when
Accept-Encoding doesn't include gzip, but only MISSes when the
adapter is gzipping. Is this by design with a respmod_precache
adapter, or can I gzip content that's already cached?
Regards, Jonathan Wolfe
NP: please configure your mailer to wrap lines at under 8 characters.
The web archives are *very* difficult to read by scrolling sideways for
a mile.
That sounds like the opposite of good behaviour. Can you produce full
request and reply headers flowing between the client and Squid for your
test transactions?
In the general background info:
eCAP gets pushed data from one of the in-memory data streams.
Technically it does not matter which one pre or post gets zipped. However...
When working correctly the adapter should update the Content-Encoding
and ETag headers when it changes the content. Due to the ETag
alterations required I would it expect to work best on pre-cache. So
that the validation IMS requests work.
Running it post-cache Squid would always report ETag X from the client
does not match the ETag Y in cache and send out a full new copy
(gzipping down again to X ... oops).
Amos
--
Please be using
Current Stable Squid 2.7.STABLE9 or 3.1.10
Beta testers wanted for 3.2.0.4
