Bug 38532 - Missing HTTP header "Content-Type" when response is 304, after a request with "If-Modified-Since"
Summary: Missing HTTP header "Content-Type" when response is 304, after a request with...
Alias: None
Product: Tomcat 5
Classification: Unclassified
Component: Unknown (show other bugs)
Version: 5.0.30
Hardware: All All
: P2 normal (vote)
Target Milestone: ---
Assignee: Tomcat Developers Mailing List
Keywords: RFC
Depends on:
Reported: 2006-02-06 16:58 UTC by Olivier Jaquemet
Modified: 2006-02-07 16:50 UTC (History)
0 users


Note You need to log in before you can comment on or make changes to this bug.
Description Olivier Jaquemet 2006-02-06 16:58:08 UTC
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... 
Comment 1 Olivier Jaquemet 2006-02-06 17:36:54 UTC
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! :)
Comment 2 Remy Maucherat 2006-02-06 17:55:17 UTC
Proper resolution.
Comment 3 Roy T. Fielding 2006-02-08 01:50:02 UTC
The answer is that 304 responses should not contain a Content-Type,
according to RFC 2616 section 10.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.