Re: [squid-users] ecap adapter munging cached body

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