On Fri, 31 Aug 2001, Cris Bailiff wrote:

> Here's a strange one, and I'm not sure how to go about fixing it:

I can't but agree with both your statements!

> (I get a '500' status from libcurl, and the same status text)

I don't understand, what's the '500' status you get?

> The server says 'content-length: 10' and doesn't provide any content. Its
> the servers fault, its broken. Unlike 304 (redirect), which MUST NOT have
> a body, a 302 is described by rfc2616 as allowing a body, generally
> containing a user readable redirection link, so a content-length header
> is legal, and can't just be ignored.

I think this calls for something to get changed in the library. I don't think
the right decision would be to just convert this error into an informational
message, as there might be applications/people who actually want to know
about this situation, and it _is_ an HTTP "error". Or would it?

I wonder if we could come up with some kind of system to turn optional
"problems" or "violations" into mere informationals...? Like
curl_allow_protocol_abuse_if_you_can_continue_anyway() ?

> Because the server says 'connection: close', I guess there's little risk
> in this, as the client can't get out of sync with the server like it
> would with a keep-alive request.

If it hand't sent "connection: close", libcurl would've been "hanging" there,
waiting for the 10 octets to get sent (until timeout occurred from either
side), as otherwise it wouldn't have known when the response ended.

> I could probably fudge my app to look for 302 status and ignore the
> failure (I think libcurl lets me see the real status, despite the
> failure, didn't look yet)

It should.

> is it an issue that libcurl should/could address, for maximum
> compatibility with 'standard' (broken) http clients?

Yes of course. The question is only how we control it.

-- 
    Daniel Stenberg -- curl groks URLs -- http://curl.haxx.se/