tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "verlag.preisser@t-online.de" <verlag.preis...@t-online.de>
Subject No response buffering in Tomcat 7.0.6?
Date Thu, 13 Jan 2011 21:41:00 GMT
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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Mime
View raw message