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

In my test, yes, the web server was responding with Vary:
Accept-Encoding. But that's only because of the behavior below, where
once a non-gzipped version is cached (i.e. a request comes in first
with no Accept-Encoding header at all) all subsequent requests get the
unzipped version, even if presenting gzip in the Accept-Encoding
header.

The eCAP module does add Vary: Accept-Encoding, actually. Running the
same test without the webserver setting Vary results in the same
behavior, though - zipped response via the gzip module doesn't cache
(two MISSes in a row), and then once a nonzipped version enters the
cache, that nonzipped cached version gets served up on every request
for any incoming Accept-Encoding.

The module does not seem to touch Cache-Control or Expires headers at
all - they come through in the uncached gzipped responses just fine
(if requesting gzip encoding before anything else is cached). Are
there headers besides Vary that the module needs to add or change to
ensure that the response can be cached?

-Jon

2011/1/23 Henrik Nordström <henrik_at_henriknordstrom.net>:
> sön 2011-01-23 klockan 14:14 -0800 skrev Jonathan Wolfe:
>
>> I'm using the values of "asdf" for a bogus Accept-Encoding value that
>> shouldn't trigger gzipping, and "gzip" for when I actually want to
>> invoke the module.  To be clear, the webserver isn't zipping at all.
>
> Is the web server responding with "Vary: Accept-Encoding"?
>
>> I can change the behavior of the webserver to not include Vary:
>> Accept-Encoding for content meant to be cached by squid, but that
>> results in responses of the cached (unzipped) version even for clients
>> who accept zipped versions, once the cache is populated by a client
>> not requesting a zipped version, and that defeats the point of the
>> gzip module for me because I want to gzip cached content for clients
>> that support it.
>
> Sounds like the gzip eCAP module handles things in a bad manner. It
> should add Vary, and it's responses should be cacheable if the original
> response is. Seems it does neither..
>
> Regards
> Henrik
>
>
Received on Mon Jan 24 2011 - 01:25:17 MST