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=13846>. 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=13846 If-Modified-Since results in incorrect headers Summary: If-Modified-Since results in incorrect headers Product: Tomcat 4 Version: 4.1.12 Platform: All OS/Version: Other Status: NEW Severity: Normal Priority: Other Component: Connector:Coyote JK 2 AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] I reported this a while ago regarding Tomcat 3.3 (http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13662). It seems however that a (symptomatically) similar problem exists in Tomcat 4.1.12. 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 . " My setup is: Tomcat 4.1.12 with a Coyote HTTP/1.1 Connector on port 18000 Apache 1.3.26 using mod_jk on port 80 forwards all traffic using mod_jk to a Coyote JK 2 connector (on port 8009). Consider the following going through apache -> jk -> tomcat: $ curl -I http://rhubarb/images/bit.gif HTTP/1.1 200 Date: Tue, 22 Oct 2002 11:52:32 GMT Server: Apache/1.3.26 (Unix) mod_jk/1.1.0 DAV/1.0.3 mod_ssl/2.8.10 OpenSSL/0.9.6g ETag: W/"48-1032511407000" Last-Modified: Fri, 20 Sep 2002 08:43:27 GMT Content-Length: 48 Content-Type: image/gif $ curl -I http://rhubarb/images/bit.gif -H 'If-Modified-Since: Fri, 20 Sep 2002 08:43:27 GMT' HTTP/1.1 304 Date: Tue, 22 Oct 2002 11:55:28 GMT Server: Apache/1.3.26 (Unix) mod_jk/1.1.0 DAV/1.0.3 mod_ssl/2.8.10 OpenSSL/0.9.6g Content-Length: 0 Content-Type: text/plain The second 'curl' command shows the problem. We have two headers (Content-Length and Content-Type) that shows strange things. Clearly this breaks the spec, and does cause problems in example mod_proxy (see above mentioned bug report). However, if I go directly towards port 18000 of my Tomcat, I get the correct result: $ curl -I http://rhubarb:18000/images/bit.gif HTTP/1.1 200 OK ETag: W/"48-1032511407000" Last-Modified: Fri, 20 Sep 2002 08:43:27 GMT Content-Type: image/gif Content-Length: 48 Date: Tue, 22 Oct 2002 11:59:03 GMT Server: Apache Coyote/1.0 $ curl -I http://rhubarb:18000/images/bit.gif -H 'If-Modified-Since: Fri, 20 Sep 2002 08:43:27 GMT' HTTP/1.1 304 Not Modified Content-Length: 0 Date: Tue, 22 Oct 2002 11:59:17 GMT Server: Apache Coyote/1.0 Second 'curl' have no strange headers. This is why I suspect Coyote JK 2 to be the problem. I'm speculating this is due to a DEFAULT_CONTENT_TYPE set in the Coyote JK connector (org.apache.coyote.Constants). But I haven't looked closely enough to verify this, and also I'm not sure what the remedy should be. The DEFAULT_CONTENT_TYPE I assume is there for a reason even though I don't understand why a Connector would interfere with any headers (wouldn't it be cleaner if the Connector only passed on whatever Tomcat tells it, and don't try to add it's own bits on top?). I am happy to sort this one out myself, but I would appreciate getting pointed in the right direction. Should I make a special case in the Connector for 304 errors (and then clear these headers), or should the Connector not have default types? Martin Algesten -- To unsubscribe, e-mail: <mailto:tomcat-dev-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:tomcat-dev-help@;jakarta.apache.org>