Mailing-List: contact commons-httpclient-dev-help@jakarta.apache.org;
 run by ezmlm
Date: 5 May 2003 14:30:49 -0000
Message-ID: <20030505143049.2110.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

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 ortwin.glueck@nose.ch  2003-05-05 14:30 -------
Ah I guess I understand the problem now. So forget about my comments.

Well, actually it's a little hard to try and fix this server problem on the
client side... I mean, if the server sends a body even though it is supposed not
to, then who on earth tells us *that* it sent this body. The real problem is, we
do not *when* this body will arrive.

The body could (in theory) arrive a long time (HTTP/1.1 keep-alive connections)
after the headers were sent. We can not just wait for an indefinite time after
each HEAD request just because some response body might arrive unexpectedly, can we?

As I see it, we *can not* recover from such a protocol violation on the same
connection - we just can not detect this situation well enough. We can only
detect that there is not HTTP/1.x response in the body and correctly assume taht
something went wrong. We can then only close the connection and retry with a
fresh one.