Hi Casper,
Looking at the source of SimplePageCachingFilter that extends from
CachingFilter [1] i think it might be a bug in the
GenericResponseWrapper class [2].
An instance GenericResponseWrapper maintains its own state for the
content type and headers and ignores those on the underlying wrapped
response.
You can verify this by extending from SimplePageCachingFilter and
overriding the methods on CachingFilter for setting the headers and
content type.
Paul.
[1]
http://www.java2s.com/Open-Source/Java-Document/Cache/ehcache/net/sf/ehcache/constructs/web/filter/CachingFilter.java.htm
[2]
http://www.java2s.com/Open-Source/Java-Document/Cache/ehcache/net/sf/ehcache/constructs/web/GenericResponseWrapper.java.htm
On Nov 9, 2009, at 11:28 AM, Casper Bang wrote:
> 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
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>