Bug 38532

Summary:	Missing HTTP header "Content-Type" when response is 304, after a request with "If-Modified-Since"
Product:	Tomcat 5	Reporter:	Olivier Jaquemet <olivier.jaquemet>
Component:	Unknown	Assignee:	Tomcat Developers Mailing List <dev>
Status:	RESOLVED INVALID
Severity:	normal	Keywords:	RFC
Priority:	P2
Version:	5.0.30
Target Milestone:	---
Hardware:	All
OS:	All

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... 
http://www.w3.org/Protocols/rfc2616/rfc2616-sec7.html#sec7.2.1

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:

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.