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: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] 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: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
