> 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
