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@xxxxxxxxxxxxxxxxxxx>: > 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 > >
