Return-Path: Mailing-List: contact commons-httpclient-dev-help@jakarta.apache.org; run by ezmlm Delivered-To: mailing list commons-httpclient-dev@jakarta.apache.org Received: (qmail 53469 invoked from network); 6 May 2003 15:47:27 -0000 Received: from exchange.sun.com (192.18.33.10) by daedalus.apache.org with SMTP; 6 May 2003 15:47:27 -0000 Received: (qmail 9323 invoked by uid 50); 6 May 2003 15:49:31 -0000 Date: 6 May 2003 15:49:31 -0000 Message-ID: <20030506154931.9322.qmail@nagoya.betaversion.org> From: bugzilla@apache.org To: commons-httpclient-dev@jakarta.apache.org Cc: Subject: DO NOT REPLY [Bug 19235] - Problem with redirect on HEAD when (bad, naughty) server returns body content X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . 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:

HTTP/1.1 301 Moved permanently

Ask server admin for details.

Which would cause the problem that I'm guessing the original poster saw if there was no CRLF after the 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.