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" <jamie_at_shareable.org> 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
Received on 2009-04-23