> > When using persistent connections and mixing HEAD and GET commands libcurl
> > may read the (wrongly sent) body of a HEAD command as the header of the
> > GET command.
> What can we do about this? As I can see it, there are only a few existing
> possibilities:
> 3) Try to detect this situation and adjust accordingly. Can this be done?

I believe the following describes the situation and the means to recognise it:
* cURL sends the HEAD request
* server sends the HTTP response headers
* cURL sends the next request
* server sends the body from the previous response
* currently cURL attempts to parse this body as an HTTP response, however it is
(statisticly speaking) very unlikely that this body will look like a valid HTTP
response header.

I suspect that tighter parsing/validation of the response may close down most
cases of problems with this sort of misbehaving server. In particular, how often
will the first few characters of a body start with "HTTP/#.# " followed by the
ascii representation of a number between 100 & 599 followed by a blank? If it
doesn't, then its not an HTTP response and you know something's up and can
"error case" out (rather than what I believe you have currently described as the
path cURL takes, which seems to be misparsing of the (incorrectly returned) body
as a header). I'd think that this would be appropriate logic to run even when
the previous request on a connection was not HEAD (as the data being returned
seems to not be an HTTP response unless it followes that format, eh? ;-).

Peace. -njg

-------------------------------------------------------
This sf.net email is sponsored by: Dice - The leading online job board
for high-tech professionals. Search and apply for tech jobs today!
http://seeker.dice.com/seeker.epl?rel_code=31
Received on 2002-08-01