You are almost right. Two reason why almost. Imagine a middle layer, a component or a library (that we really have in this case) between curl and the final application that makes the http transfer.
1. That layer has it's own error handling and logging and that layer could not detect and log this error now. 2. Imagine that layer has a function let's call it HTTPGet. When the user calls this function she/he can try to get a web sever page, a really large file or just like in our case a web camera endless stream. Any of these can end in a server side disconnection. If there is no returning CURL error code from the function in the case of disconnection (just like now) in the first case the function caller have to validate the page to detect if it's a full page, in the second case must try to check the file size and in the final case just skip error checking. Three different kind of reaction for the same error instead of just simply compare the returning error code with a well defined error value. Which one is more simple? Which one is more general solution? The main problem is here in my opinion that curl which is a lower level layer tries to decide what is error an what is not. I think letting the user decide what error she/he would like to ignore and what not is a much more better solution. I like curl because it has a really flexible, general interface and I think how it's handling this problem is none of that two. Just my two cents Bests Hofi On 2009.04.23. 13:30, "Jamie Lokier" <[email protected]> wrote: > Istvan Hoffmann wrote: >> 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). > > So you don't need curl to tell you it's an error. You know it's an > error when curl says it's finished on that resource, because _you_ know > that should not happen _for that resource_. > >> 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? > > Why do you need that option? If you have to change your application > to set the option, it means you want to use HTTP in a special way for > a particular resource. Because you know the resource is an infinite > stream, it should not end. So you can just instead change your > application to say that "end of transfer" is an error for this > resource. > > (It would be better if you can change the server to use chunked > encoding though.) > > -- Jamie
