I'm exploring caching options with Jersey, particularly ways to utilize
EhCache. For a simple high-performance read-only Jersey instance, the
SimplePageCachingFilter that comes with EhCache is an interesting option
as it caches a gzipped HTTP response right at the forefront. However I
noticed that when the filter is activated, it does not forward the
original Content-Type from lower down the filter chain (Jersey). An
example without caching:
Server Apache-Coyote/1.1
Content-Type application/xhtml+xml
Transfer-Encoding chunked
Date Sun, 08 Nov 2009 10:13:02 GMT
And now, with caching:
Server Apache-Coyote/1.1
Content-Encoding gzip
Content-Length 1130
Date Sun, 08 Nov 2009 10:15:58 GMT
I wonder what goes wrong, whether I am not using it correctly. In my
web.xml, the caching filter is listed before the Jersey filter and apart
from this header rewrite, everything works flawlessly. I assume it's not
simply because the caching filter automatically compresses the cached
response, even if compressed, the Content-Type would still be relevant
to the client? According to rfc2616 my expectation is entirely valid:
14.11 Content-Encoding
The Content-Encoding entity-header field is used as a modifier to the
media-type. When present, its value indicates what additional content
codings have been applied to the entity-body, and thus what decoding
mechanisms must be applied in order to obtain the media-type
referenced by the Content-Type header field. Content-Encoding is
primarily used to allow a document to be compressed without losing
the identity of its underlying media type.
Can anyone shed some light on what goes on here? I realize this is more
suitable to be addressed to EhCache developers but I've had no response
from there and I assume the general topic of caching is relevant to many
developers using Jersey. Could this be an oversight/bug in the filter?
Thanks,
Casper