DO NOT REPLY [Bug 13846] New: - If-Modified-Since results in incorrect headers

[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=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: tomcat-dev@jakarta.apache.org
        ReportedBy: puckman@taglab.com


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:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>