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.
View this message in context:
Sent from the Resin mailing list archive at Nabble.com.
resin-interest mailing list