Re: Serverside disconnection vs. simple Closing connection #n
Date: Thu, 23 Apr 2009 20:24:38 +0100
Istvan Hoffmann wrote:
> 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
> 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
> 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.
What are you proposing?
Clearly curl cannot report an "error" when the connection closes with
these HTTP headers, because that's a normal way to end a successful
transfer in HTTP. (But servers should change to using HTTP/1.1
chunked encoding, so that they can indicate server-side errors.)
I think you're asking for another option where you tell curl to report
closed-connection with these headers as an error.
But how does that help your middle layer? If you are going to enable
the option in your middle layer HTTPGet, why not instead just report
end-of-file as an error to the application?
I don't see how adding a curl option helps you to write the middle
layer, when you can do the same thing without the option.
Received on 2009-04-23