According to the HTTP spec, if a server includes an ETag header when it sends a file, it must also include the ETag when it sends a 304 (not-modified) response for that file. Tomcat does not do this for static files - if you request a static file and get a 200 response, the response has an ETag header; but if you get a 304 resopnse, the ETag is omitted. To reproduce: - In a browser, request a static file from Tomcat (e.g. http://localhost/tomcat.gif) - Make sure you get a 200 response (force reload or clear browser cache) - Examine the response headers (using a browser plugin or whatever) - note that there is an ETag header - Request the same file again, getting a 304 (not-modified) response from Tomcat - Examine the response headers - note there is no ETag The 304 response should include an ETag header, because the 200 response had one. Spec reference: RFC 2616 section 10.3.5 says: "304 Not Modified [...] The response MUST include the following header fields: [...] - ETag and/or Content-Location, if the header would have been sent in a 200 response to the same request"
Created attachment 20251 [details] Request and response headers showing the problem I have attached a log file from Firefix LiveHTTPHeaders showing the problem. A static file is requested twice. The first response is a 200 with an ETag header, the second response is a 304 without an ETag header.
I see how to fix this, but I'm not set up to compile Tomcat so someone else will have to make the change and test it. In org.apache.catalina.servlets.DefaultServlet, the serveResource method sets an ETag header when it serves a file with a 200 or 206 response. To get it to add the ETag to 304 responses, this needs to be added: response.setHeader("ETag", getETag(resourceAttributes)); in two places where a a status of 304 (SC_NOT_MODIFIED) is set, in the methods checkIfModifiedSince and checkIfNoneMatch.
(I've changed the Component to "Catalina" because none of the more specific Components seem appropriate. If that's wrong, please correct it.)
Thanks for the patch. It has been applied to svn and will be in 5.5.24 and 6.0.14 onwards.
Tested OK in 5.5.24 release candidate.