The "Content-Type" header is not returned by tomcat when accessing file that have not changed since the last access. To reproduce: - store a static file on server, say myfile.xls - access the file a first time (with IE), everthing work as expected, the "Content-Type" is provided by Tomcat. - access the file a second time (with IE), IE provides a "If-Modified-Since" header and Tomcat response is 304, as expected, but the "Content-Type" header is missing and IE goes crazy. It works well with firefox 1.5 as it does not provide the "If-Modified-Since". The HTTP 1.1 RFC states: "Any HTTP/1.1 message containing an entity-body SHOULD include a Content-Type header[...]", a 304 response is not an entity-body.. therefore it does not really violate any RFC, but it is not the behavior expected by the (current) main browser IE... http://www.w3.org/Protocols/rfc2616/rfc2616-sec7.html#sec7.2.1
Just for information, as I don't desesperately want this bug to be solved, could you provide the explanation on why this bug won't be fixed? That way I'll try not to submit bug of the same kind in order to limit the amount of bugs you need to deal with. Thanks! :)
Proper resolution.
The answer is that 304 responses should not contain a Content-Type, according to RFC 2616 section 10.3.5: http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.3.5 If the conditional GET used a strong cache validator (see section 13.3.3), the response SHOULD NOT include other entity-headers. Otherwise (i.e., the conditional GET used a weak validator), the response MUST NOT include other entity-headers; this prevents inconsistencies between cached entity-bodies and updated headers. MSIE does not "go crazy" when receiving a 304 response, so my guess is that the 304 has nothing to do with the observed problems.