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" <[email protected]> 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?
