This http connection is a stream transfer, after the connection established
and received the headers the body part transfer will keep to the end of the
time (or to user break or server disconnection).

The response headers are the following

Cache-Control: no-cache
Pragma: no-cache
Expires: Thu, 01 Dec 1994 16:00:00 GMT
Connection: close
Content-type: multipart/x-mixed-replace; boundary=--myboundary

So from a point of view the connection close might not be an error but in
our case this is definitely an error and I could not find a direct method to
detect.
As I mentioned there is an indirect way that says every return from the
curl_easy_perform can be treated as server side disconnect, but I'd prefer a
real concrete error code from curl about the real reason just like I got
when f.e. interrupting the transfer from one of the installed callbacks.

May be as a deal you can add a new option that can be set via
curl_easy_setopt to let the user control if curl treats a server side
disconnection as an error or just an ignorable warning?
What do you think?

On 2009.04.22. 22:42, "Daniel Stenberg" <daniel_at_haxx.se> wrote:

> On Wed, 22 Apr 2009, Istvan Hoffmann wrote:
>
>> I'm really wondering is there any special reason why that function not set
>> result error to something like CURLE_GOT_NOTHING or CURL_PEER_DISCONNECTED
>> (which is totally not existing in the error code defined list, I know) to
>> let inform the caller the real reason of closing the connection.
>>
>> I'm also interesting it if I would modify the code mentioned above to return
>> with an error result, would it case any problem in any cases later.
>
> The reason is that in most cases the server closure is not an error, and for
> the cases where the close is an error we are able to detect it otherwise.
>
> How is your case actually an error HTTP-wise? What response headers does
> libcurl get before the stream starts?
Received on 2009-04-23