DO NOT REPLY [Bug 13662] New: - If-Modifed-Since results in incorrect Content-Type header

[bu...@apache.org]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13662>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13662

If-Modifed-Since results in incorrect Content-Type header

           Summary: If-Modifed-Since results in incorrect Content-Type
                    header
           Product: Tomcat 3
           Version: 3.3.1 Final
          Platform: All
        OS/Version: Other
            Status: NEW
          Severity: Normal
          Priority: Other
         Component: Unknown
        AssignedTo: tomcat-dev@jakarta.apache.org
        ReportedBy: puckman@taglab.com


When doing an "If-Modified-Since" request against a static file 
(StaticInterceptor), in the case of a "304 Not Modified", the Content-Type 
header is always supplied as "text/html". 

This results in problems in our apache httpd 1.3.26 mod_proxy reverse proxy 
cache. mod_proxy updates the Content-Type field of the object with the new 
data. E.g. a gif file will upon entering the cache have the correct 
type "image/gif", but when anyone does an "If-Modified-Since" request and the 
cache asks tomcat if the content is up to date, the type gets overwritten 
with "text/html" which was supplied by tomcat. This then results in images 
with the wrong content type.

According to W3C spec of 304 response header 
(http://www.w3.org/Protocols/HTTP/HTRESP.html):
"Response headers are as if the client had sent a HEAD request, but limited to 
only those headers which make sense in this context. This means only headers 
that are relevant to cache managers and which may have changed independently 
of the document's Last-Modified date. Examples include Date , Server and 
Expires . "

I suspect mod_proxy interprets this *very* broadly and updates most headers 
that are sent over. Arguably changing the Content-Type does not make sense in 
this context, and such both Apache httpd and Apache Tomcat should change the 
behaviour.

Consider the following:

$ curl -I http://mytomcat:18000/images/bit.gif
HTTP/1.0 200 OK
Content-Type: image/gif
Content-Length: 48
Last-Modified: Thu, 03 Oct 2002 15:49:27 GMT
Date: Tue, 15 Oct 2002 16:46:03 GMT
Server: Tomcat Web Server/3.3.1 Final ( JSP 1.1; Servlet 2.2 )

$ curl -I http://mytomcat:18000/images/bit.gif -H "If-Modified-Since: Thu, 03 
Oct 2002 15:49:27 GMT"
HTTP/1.0 304 Not Modified
Content-Type: text/html
Date: Tue, 15 Oct 2002 16:46:22 GMT
Server: Tomcat Web Server/3.3.1 Final ( JSP 1.1; Servlet 2.2 )

The second 'curl' shows the problem.

A quick fix is not to send the Content-Type header on 304. I believe that 
would also be more close to spec. Looking at the Tomcat code I've found that 
the internal StatusHandler always sets "text/html". Here is a patch that makes 
the StatusHandler only do that in case it isn't a 304:

$ diff -u ErrorHandler.java-2002-10-15 ErrorHandler.java
--- ErrorHandler.java-2002-10-15        Tue Mar 26 15:36:55 2002
+++ ErrorHandler.java   Tue Oct 15 18:56:23 2002
@@ -683,7 +683,6 @@
        String msg=(String)req.getAttribute("javax.servlet.error.message");
        String errorURI = res.getErrorURI();

-       res.setContentType("text/html");
        // res is reset !!!
        // status is already set
        int sc=res.getStatus();
@@ -691,6 +690,11 @@
        if( sc == 304 ) {
            //NotModified must not return a body
            return;
+       } else {
+         // don't set a content type if we are answering If-Modified-Since.
+         // Proxy caches might update their cached content-type with this
+         // info (mod_proxy does it). Martin Algesten 15th Oct, 2002.
+         res.setContentType("text/html");
        }

        if( sbNote==0 ) {

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>