You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Konstantin Preißer <ko...@t-online.de> on 2010/12/03 14:25:50 UTC

RE: Tomcat Jakarta 1.2.31 ISAPI Reconnector incorrectly sending Content body with HTTP 304 Status

> Now if I do a GET-Request with an "If-modified-since" header to a file
which
> doesn't exist, Tomcat returns a 302 Not Modified response instead of 404
Not
> Found. I think this is because Tomcat compares the date after the
> "Is-modified-since" header to the date of the static 404 error file, thus
> returning 302 instead of 404.

Hello,

does anybody have an idea, why Tomcat has this behavior, when using a static
html file for 404 errors?
To reproduce this, use a static html file as custom 404 error page, and do a
GET request with an "If-Modified-Header" (the date may be in the future),
e.g.

GET /mywebapp/AUrlToAFileWhichDoesNotExist.gif HTTP/1.1
Host: www.mydomain.net
Keep-Alive: 115
Connection: keep-alive
If-Modified-Since: Tue, 08 Nov 2015 15:07:52 GMT

Now Tomcat always will return "302 Not Modified" instead of "404 Not Found".
When the "If-Modified-Since" header is omitted, Tomcat correctly returns
"404 Not Found", but adds a "Last modified:" header containing the date of
the 404 file. Is this a configuration error or a bug?

I think the reason for the ISAPI Redirector to use chunked encoding instead
of Content-Length for such 302 responses is Bug 49591 - "Custom error page
always uses Transfer-Encoding: chunked" (on Bugzilla).
So I think the reasons which caused my original problem with the connector
were:

1) The browser sends a Get-Request with an "If-Modified-Since" header to a
file which doesn't exist.
2) Tomcat is using the custom 404 error page for the resulting 404 error,
but then is comparing the date of the "If-Modified-Since" against the 404
html file, thus returning "302 Not Modified" instead of "404 Not Found".
3) Because of Bug 49591, Tomcat is using chunked encoding for custom
errorpages, so it uses chunked encoding for that 302 response. But Tomcat's
HTTP connectors seems to remove the transfer-encoding header and the content
body.
4) The unfixed 1.2.31 ISAPI connector doesn't check for 302 responses
(#50363) to decide whether to use chunked encoding, and because I enabled
chunked encoding (which is disabled by default), this finally caused the
invalid response I was seeing.

Seems like a "chain of unfortunate circumstances" then. ;)

Konstantin


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org