Summary: | Tomcat returns 304 instead of 404 response for static custom 404 error file | ||
---|---|---|---|
Product: | Tomcat 5 | Reporter: | Konstantin Preißer <kpreisser> |
Component: | Catalina | Assignee: | Tomcat Developers Mailing List <dev> |
Status: | RESOLVED FIXED | ||
Severity: | minor | ||
Priority: | P2 | ||
Version: | 5.5.31 | ||
Target Milestone: | --- | ||
Hardware: | PC | ||
OS: | Windows XP |
Description
Konstantin Preißer
2010-12-05 07:34:55 UTC
Sorry, when I wrote "302 Not Modified" I actually ment "304 Not Modified". Thanks for the report. This has been fixed in 7.0.x and will be included in 7.0.6 onwards. (In reply to comment #2) > Thanks for the report. This has been fixed in 7.0.x and will be included in > 7.0.6 onwards. Thanks :) I would like to note that the same behavior/bug exists in Tomcat 6.0.29 and 5.5.31 as well (I just tested it on these versions). Sorry I didn't that before. Maybe the fix needs to be backported? Cheers Konstantin Re-open against 5.5.x so it gets fixed in 5.5.x and 6.0.x Fixed in 6.0.x and will be included in 6.0.30 onwards. One minor glitch with the current fix for this issue: (regards 7.0, 6.0 and proposed patch for 5.5) In DefaultServlet#serveResource(..) there is the following condition: if ( (cacheEntry.context != null) || ( ((ranges == null) || (ranges.isEmpty())) && (request.getHeader("Range") == null) ) || (ranges == FULL) ) { Note the following part of it: (ranges == null || ranges.isEmpty()) && (request.getHeader("Range") == null) With the current fix for this issue a "parseRange(request, response, cacheEntry.attributes)" call is skipped and thus "ranges" remains to be null, but request.getHeader("Range") still returns the original header. ============================================================================== Using MyWebApp with a custom 404.html page, as described by OP, I now get: In current 7.0.x (at rev.1056780) -- Request: GET /MyWebApp/AUrlToAFileWhichDoesNotExist.gif HTTP/1.1 Host: localhost Keep-Alive: 115 Connection: keep-alive Range: bytes=0-499 -- Response: HTTP/1.1 404 Not Found Server: Apache-Coyote/1.1 Transfer-Encoding: chunked Date: Sat, 08 Jan 2011 20:49:46 GMT 0 -- Request: (without the "Range" header) GET /MyWebApp/AUrlToAFileWhichDoesNotExist.gif HTTP/1.1 Host: localhost Keep-Alive: 115 Connection: keep-alive -- HTTP/1.1 404 Not Found Server: Apache-Coyote/1.1 Content-Type: text/html Content-Length: 17 Date: Sat, 08 Jan 2011 20:51:02 GMT Error 404.html! -- I.e., if "Range" header was specified, the custom error page is not used at all. It is not a show stopper, as it is still better than it was before, because e.g. in 5.5.31 the response is the following: -- Request: GET /MyWebApp/AUrlToAFileWhichDoesNotExist.gif HTTP/1.1 Host: localhost Keep-Alive: 115 Connection: keep-alive Range: bytes=0-499 -- Response: HTTP/1.1 206 Partial Content Server: Apache-Coyote/1.1 Accept-Ranges: bytes ETag: W/"17-1294518367875" Last-Modified: Sat, 08 Jan 2011 20:26:07 GMT Content-Range: bytes 0-16/17 Content-Type: text/html Content-Length: 17 Date: Sat, 08 Jan 2011 21:01:35 GMT Error 404.html! -- which is wrong, because it is successful "206 Partial Content", while "404 Not Found" was expected instead. (In reply to comment #6) This is fixed by r1056889 in 7.0 - will be in 7.0.6. Proposed as an additional patch for this issue for 6.0 and 5.5. fixed in 6.0.x and will be in 6.0.31 onwards Will be in 5.5.32 |