On Wed, 31 Jul 2002, Nick Gimbrone wrote:

> 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?

Not very often. But what would curl do when they do? Or perhaps even worse,
what if the "illegal" response-body from the HEAD request looks like that. It
would then be impossible for curl to detect.

This strict check would of course only be required on requests done on a
persistent connection where the previous request was a HEAD.

> If it doesn't, then its not an HTTP response and you know something's up
> and can "error case" out

That would mean: it would need to close the connection and then re-connect
and re-send the request. (And in this request it wouldn't need to check the
response anymore.)

> 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? ;-).

It would make curl a lot more picky on the HTTP response format indeed. I
think I would prefer to keep it as liberal as possible in what to accept from
the remote.

Thanks a lot for sharing your views.

-- 
 Daniel Stenberg -- curl related mails on curl related mailing lists please
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf