hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 19235] - Problem with redirect on HEAD when (bad, naughty) server returns body content
Date Tue, 06 May 2003 13:23:03 GMT
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=19235>.
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=19235

Problem with redirect on HEAD when (bad, naughty) server returns body content





------- Additional Comments From eric@tibco.com  2003-05-06 13:23 -------
I still think we're chasing the wrong problem, here, and the patch makes me
uncomfortable on several fronts.

I don't think that a GET or POST response with too much data should be treated
any differently than a HEAD response with too much data.  The scan for HTTP/1.1
exists for precisely that reason.  I have not personally tried the scenario that
the original poster indicated, but it seems no different in principle than a
server that tacks an extra CRLF pair at the end of a GET response - when we read
the next response we have to scan for the HTTP/1.1 line start.  The current code
might be a problem, though, if the previous response has extra data, but doesn't
end with a CRLF.  I think THAT is the problem we should be solving.

I looked through the patch, and as best I can tell, it changes the default
behavior of the HeadMethod to wait for 100ms for invalid content.  That seems
like a bad default, at a minimum.  My application uses HEAD in a number of
places, and having to revisit all my code where HEAD is invoked just to solve a
problem I never encounter seems weird to me.  And if I miss a case, I get an
inexplicably performance penalty.  Ugh.  Maybe I read the code wrong though.

testNoncompliantHeadStrickMode - "strict" is misspelled.

I like the test cases you provided!  It is certainly a clever way to reproduce
the problem.

Mime
View raw message