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 15:49:31 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 15:49 -------
Well, I definitely think the wait should be avoided by default, otherwise you've
defeated most of the client value of the HEAD method as a less "expensive"
alternative to GET.

Since the original poster knows that he is going against a non-compliant server,
is it more appropriate to simply work around it there?  Perhaps not, or they
wouldn't have posted the bug.

I'm torn about the pattern matching problem.  The only time looking for byte
level HTTP/1.1 would generate problems is if server is genuinely misbehaving. 
The code we have now consumes the entire response even if the caller doesn't
read it all, solving many of the potential response alignment issues.  Thus in
most cases (except this one), my experience suggests we only have to worry about
the occassional stray CRLF pair. These wouldn't cause a problem with my
alternative.  Of course the problem with this particular case is that you could
easily imagine the server returning:
<html><body><h1>HTTP/1.1 301 Moved permanently</h1><p>Ask server
admin for
details.</p>
</body></html>

Which would cause the problem that I'm guessing the original poster saw if there
was no CRLF after the </html> tag.  Yet if you did a byte level search for
HTTP/1.1 as I suggest, it would still fail, as my approach would "find" the
first occurrance and try to read the header prematurely.  In the absence of a
wire log, and thinking about the potentially diabolically misbehaved servers, I
concede that your approach might be better.

Your change to HttpMethodBase puzzled me for a while, as I was worried that it
might change the performance.  Now that I look at it again, it makes more sense,
and it might prevent an exception for badly behaved servers.  Might this be a
behavior change that should be aware of "strict" mode, though?  Except wait - I
just did a search for "isStrictMode()" uses and I didn't find any, except in
your new patch.  Did this sneak in while I wasn't watching?

Sorry about the rambling, but I've been puzzling through this one, and you seem
to be quite a bit ahead of my thinking.

Mime
View raw message