> 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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
