• Bug
  • Status: Closed
  • 2 Major
  • Resolution: Duplicate
  • ehcache-web
  • Reporter:
  • November 09, 2009
  • 0
  • Watchers: 0
  • November 17, 2009
  • November 12, 2009

Description

Hello EhCache list,

I noticed that when using SimplePageCachingFilter or SimpleCachingHeadersPageCachingFilter on a vanilla Tomcat 6.0.18, it does not forward the original Content-Type from lower down the filter chain (i.e. 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 meta info would still be relevant to the client.

A quick an very dirty workaround, is to override setContentType and manually set this header by extracting it from PageInfo:

@Override protected void setContentType(final HttpServletResponse response, final PageInfo pageInfo) { super.setContentType(response, pageInfo);

   List headerList = pageInfo.getResponseHeaders();
   for(Object object : headerList){
       String[] headerItem = (String[])object;
       if(headerItem.length > 1 && headerItem[0].equals("Content-Type"))\{
           response.setContentType( headerItem[1] );
           return;
       }
   }    \}

Can anyone shed some light on why this is necessary? Paul Sandoz (JSR 311 spec lead) of Jersey speculates that GenericResponseWrapper maintains its own state for the content type and headers and ignores those on the underlying wrapped response.

Thanks in adva

Comments

Abhishek Singh 2009-11-11

Not reproducible with latest ehcache-web-1.6.0-beta3-snapshot. This issue is reproducible with ehcache-web-1.6.0-beta1 though. This is also not reproducible with ehcache-web-1.6.0-beta2 (downloaded from sourcefource, its pom from the maven repo is probably broken which has a dependency on ehcache-1.7.0 and there are no jar artifact for the same on the maven repo).

Here are some curl output for the same app (a jersey hello world app with filters), and different versions of ehcache-web jars used: 1) with ehcache-web-1.6.0-beta1 $ curl -i http://localhost:8080/helloworld-webapp-1.6.0-beta1/helloworld HTTP/1.1 200 OK Server: Apache-Coyote/1.1 Last-Modified: Wed, 11 Nov 2009 13:51:42 GMT Expires: Wed, 11 Nov 2009 16:38:22 GMT Cache-Control: max-age=10000 ETag: Wed, 11 Nov 2009 16:38:22 GMT Content-Length: 11 Date: Wed, 11 Nov 2009 13:51:42 GMT

2) with ehcache-web-1.6.0-beta2 $ curl -i http://localhost:8080/helloworld-webapp-1.6.0-beta2/helloworld HTTP/1.1 200 OK Server: Apache-Coyote/1.1 Last-Modified: Wed, 11 Nov 2009 13:51:54 GMT Expires: Wed, 11 Nov 2009 16:38:34 GMT Cache-Control: max-age=10000 ETag: “1257957514016” Content-Type: text/plain Content-Length: 11 Date: Wed, 11 Nov 2009 13:51:54 GMT

3) with ehcache-web-1.6.0-beta3-snapshot $ curl -i http://localhost:8080/helloworld-webapp-1.6.0-beta3-snapshot/helloworld HTTP/1.1 200 OK Server: Apache-Coyote/1.1 Last-Modified: Wed, 11 Nov 2009 13:52:09 GMT Expires: Wed, 11 Nov 2009 16:38:49 GMT Cache-Control: max-age=10000 ETag: “1257957529314” Content-Type: text/plain Content-Length: 11 Date: Wed, 11 Nov 2009 13:52:09 GMT

Running with both beta-2 and beta3-snapshot has the content-type header to the correct value.

gluck 2009-11-12

This got fixed in beta2. See the following excerpt from the changelog. Abishek’s testing verifies that.

Content-Type set through a header does not override implicit Content-Type

</release>

As such it is a duplicate of a resolved bug.