OK, after a bit more investigation I can replicate your responses: One is a 304 response with a response.flushBuffer() or similar, and the other is a 304 response with an implicit close.
I've tested a fix to the ISAPI Redirector to resolve this. https://issues.apache.org/bugzilla/show_bug.cgi?id=50363 cheers tim On Mon, Nov 29, 2010 at 11:10 PM, Tim Whittington <t...@apache.org> wrote: >> This is the first time I ask a question here, so I hope I do it right. >> >> I am using Tomcat 7.0.5 (with Tomcat Native 1.1.20 library) on Windows >> Server 2003 (32-Bit) with Java 1.6.0_22, and I have configured IIS6.0 to use >> the Jakarta 1.2.31 ISAPI Redirector (with "enable_chunked_encoding" set to >> "true") to connect to Tomcat (using AJP/1.3). >> I am using a simple webapp with some static files and some servlets. >> >> >> When I use the Mozilla Firefox browser to view the website (which contains >> static elements like images), I sometimes get HTTP 304 responses with a >> content, which look like this: >> >> HTTP/1.1 304 Not Modified >> Date: Sat, 27 Nov 2010 15:46:09 GMT >> Server: Microsoft-IIS/6.0 >> ETag: W/"1285-1289228872000" >> Transfer-Encoding: chunked >> >> 0 >> >> HTTP/1.1 304 Not Modified >> Date: Sat, 27 Nov 2010 15:46:09 GMT >> Server: Microsoft-IIS/6.0 >> ETag: W/"15480-1290865988000" >> Content-Length: 0 > > I'm a little confused by the examples here - is this the content of > one response, or multiple responses? > Testing with the (non APR) AJP connector, I can reproduce the > Content-Length: 0 response, which although 'quirky' is still valid (as > long as the entity body is indeed empty). I can't reproduce the > Transfer-Encoding: chunked response. > >> But in the RFC2616 it says that an HTTP 304 Response "must not contain a >> message-body, and thus is always terminated by the first empty line after >> the header fields." This leads Firefox sometimes to display the whole HTTP >> headers of the next response and the content as plain text, because it >> doesn't expect a Transfer-Encoding Chunked body ("0" + line separator) after >> the headers of that HTTP 304 response. >> >> Now if I set the "enable_chunked_encoding" setting to "false" for the ISAPI >> Redirector, the responses look like this: >> >> HTTP/1.1 304 Not Modified >> Date: Sat, 27 Nov 2010 16:44:18 GMT >> Server: Microsoft-IIS/6.0 >> ETag: W/"15480-1290865988000" >> Content-Length: 0 >> >> HTTP/1.1 304 Not Modified >> Connection: close >> Date: Sat, 27 Nov 2010 16:45:13 GMT >> Server: Microsoft-IIS/6.0 >> ETag: W/"1285-1289228872000" > > Again, this is a bit confusing. The Connection: close looks like the > ISAPI Redirector (this is what IIS will do if you don't tell it how to > keep the connection alive), but I'm confused about what is generating > the AJP response it is processing. The Java AJP connectors in Tomcat > appear to explicitly set the Content-Length to 0 on empty 304 > requests, so I'm puzzled as to how you managed to create this > scenario. > >> This time it works with Firefox Browser (as no additional content follows >> after the header), but even here it's still not correct, as I get a >> "Content-Length: 0" header with the HTTP 304 Response (or a "Connection: >> close" as the compensation for the disabled Chunked Encoding), although >> there actually can't be any content. >> >> My question is, why does the ISAPI Redirector send a Content body with an >> HTTP 304 Response, although RFC 2616 doesn't allow it? Is there some way to >> correct this behavior? I just used the "IIS HowTo" from the Tomcat Connector >> Documentation to configure the ISAPI Redirector, and I would like to enable >> the "chunked_encoding" setting because it improves performance. >> Tomcat itself (HTTP/1.1 connector) doesn't send a "Content-length" or >> "Transfer-Encoding" header on a HTTP 304 response. > > I think this is a bug in the redirector - it's not checking for > 204/205/304 response codes when determining whether to chunk encode. I > can fix this, but I'd like to know how your responses are being > generated the way they are. > > cheers > tim > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
