> Not sure this is a bug with GzipFilter or expected behavior, but found
> something worth sharing and dropping in the forum record for others to find.
> We had a problem distributing content to a CDN and keeping it in cache there
> because the CDN was requesting content with an "Accept-Encoding: gzip"
> request header, which was causing our GzipFilter to slap a "Cache-Control:
> private" response header via the http response object. Our file servlet (an
> extension of the default resin file servlet) was adding a Cache-Control
> header with "max-age=840000, public" that the GzipFilter ended up writing
> "Cache-Control: max-age=84000, public, private". In our testing, we were
> using curl to test/examine the headers, so we didn't pick up that the
> private cache control header was being added. Our CDN provider, however,
> was testing with a user agent that indicated it accepted the gzip encoding
> and was thus seeing the cache-control header appear. Made for a lively
> debate. Thus, they were seeing the private declaration and not caching the
> So, we had to add an exclude-pattern to our GzipFilter configuration to not
> pick up files in the directory we wanted to control caching on. So, fyi,
> either GzipFilter has a bug in that it is not honoring Cache-Control headers
> set by responses further downstream, or it is operating properly and you
> must remember to disable the GzipFilter on content you want to be cached
> publicly. It would be nice if GzipFilter honored cache-control directives.
> configuration e.g.:
The private cache-control is added by Resin Cache in this case(not gzip filter
) following the value set in resin.conf <cache><rewrite-vary-as-private.
It has to do with the IE bug (outlined in more detail at :
> View this message in context:
> Sent from the Resin mailing list archive at Nabble.com.
> resin-interest mailing list
resin-interest mailing list