Good afternoon, some weeks ago, I posted a question about the ISAPI redirector using chunked encoding for 304 responses (Topic: Tomcat Jakarta 1.2.31 ISAPI Reconnector incorrectly sending Content body with HTTP 304 Status) which created invalid responses. These issues were fixed in Tomcat 7.0.6 and not yet released Tomcat Connectors 1.2.32 (thanks to the Tomcat devs, see https://issues.apache.org/bugzilla/show_bug.cgi?id=50363 and https://issues.apache.org/bugzilla/show_bug.cgi?id=50413).
However, when I tried the new Tomcat 7.0.6 these days, I got again a strange issue regarding 304 responses with ISAPI redirector. It seems that Tomcat 7.0.6 doesn't use a output buffer any more. Consider this simple jsp: <%= "hello!" %> Running the jsp in Tomcat 7.0.5, the request and response look like this: GET /simple.jsp HTTP/1.1 Host: localhost Keep-Alive: 115 Connection: keep-alive HTTP/1.1 200 OK Server: Apache-Coyote/1.1 Set-Cookie: JSESSIONID=0AFC2875C06A962DF8A02DE6A780F721; Path=/; HttpOnly Content-Type: text/html;charset=ISO-8859-1 Content-Length: 6 Date: Thu, 13 Jan 2011 21:16:23 GMT hello! (note the Content-Lengh header, which indicates that the output has been buffered). However, running in Tomcat 7.0.6, the response look like this: GET /simple.jsp HTTP/1.1 Host: localhost Keep-Alive: 115 Connection: keep-alive HTTP/1.1 200 OK Server: Apache-Coyote/1.1 Set-Cookie: JSESSIONID=2C176DBAC054D5BBF3D99FBE5C026915; Path=/; HttpOnly Content-Type: text/html;charset=ISO-8859-1 Transfer-Encoding: chunked Date: Thu, 13 Jan 2011 21:23:19 GMT 6 hello! 0 i.e. chunked encoding is applied to the response, although it should easily fit into the output buffer. Now, the same is used for "304 Not Modified" responses when accessing static content. Normally, when the DefaultServlet returns a 304 status because the requestet resource has not modified, it writes a content-length: 0 header, but it is removed by the Tomcat HTTP connector (according to Tim Whittington's description). However the ISAPI redirector did not remove the header, and the response looked like this: HTTP/1.1 304 Not Modified ETag: W/"13614-1291405552000" Server: Microsoft-IIS/7.0 X-Powered-By: ASP.NET Date: Thu, 13 Jan 2011 21:27:06 GMT Content-Length: 0 This was still a valid response. But with Tomcat 7.0.6, using the ISAPI redirector with chunked encoding support enabled, I get the following response: HTTP/1.1 304 Not Modified Transfer-Encoding: chunked ETag: W/"13614-1291405552000" Server: Microsoft-IIS/7.0 X-Powered-By: ASP.NET Date: Thu, 13 Jan 2011 21:27:06 GMT 0 which is invalid. The issue is fixed for the next version of the ISAPI redirector (1.2.32), but it is not released yet, so I can't use the new version. Disabling chunked encoding would solve the invalid response symptom, but I would like to continue using use chunked encoding. Does anybody know why Tomcat uses chunked encoding instead of content-length header (output buffering)? Thanks, Konstantin Preisser --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
