DO NOT REPLY [Bug 13846] - 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





------- Additional Comments From Brian.Ewins@btinternet.com  2002-11-11 18:52 -------
I looked into this 'cos I was skeptical, but you're right, this breaks the spec.
206 (Partial) responses to If-Range requests, and 304 (Not Modified) responses
shouldn't include entity-headers in most circumstances, and /must not/ include
them in every other circumstance. i.e. the best thing to do is remove any of
them from a response. Sections 10.2.7 and 10.3.5 of the http 1.1 spec; the
entity headers that shouldn't be sent are listed in sec 7.1.

Near as I can tell the problem is in
org.apache.coyote.http11.Http11Processor.prepareResponse(), where it only
excludes a couple of entity headers on the basis that they're disallowed (should
remove all of them). What's in there is a hack round the inability to remove
headers from org.apache.tomcat.util.http.MimeHeaders, and it smells. A better
idea might be to have a 'MimeHeaderFilter' than applies the rules (eg
EntityHeaderFilter); whats more is it doesn't handle the 206 case at all.

FWIW, I'd also agree that the default content type shouldn't be being added
after the headers have already been 'validated' (since thats what
prepareResponse claims to do) - that doesn't make a lick of sense.

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