You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Martin Algesten <pu...@taglab.com> on 2002/12/10 12:32:29 UTC
[PATCH] More Content-Type problems with 304 responses (Tomcat3.3.1)
Hello...
I had a problem a while ago with If-Modified-Since responses 304 always
set the Content-Type to "text/plain" which consequently pollutes
web-caches that updates their cached entries with the new Content-Type.
E.g. if we request a GIF, the content type in the cache will the first
time be set to "image/gif", if a subsequent "If-Modified-Since" request
makes the cache revalidate against it source Tomcat and tomcat says "304
Not Modified" and "Content-Type: text/plain", the cache will update its
cached entry to have the wrong content type.
The bug fix that time was to make sure Tomcat 3.3.1 does not set the
content type on a 304 response.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13662
This works as long as tomcat is not behind an Apache 1.3.27 server. That
apache server has got a "DefaultType" directive which is the type to use
for a requested resource does not have a type.
Well, the patch mentioned above just removed the type for 304 responses,
and consequently apache adds its default type, which arguably is wrong
in apache, but we can do a minor fix it in tomcat to get better
interoperability.
Basically it is fine with the http spec to set the Content-Type in a 304
response as long as it is the correct type (e.g. calling a gif a gif).
The patch submitted moves the "check content type block" to be before
the "answer 304 response block". Which means we always set the content
type, even on a 304 response, but it will be the correct type.
Martin