On Wed, 9 Apr 2008, Dan Fandrich wrote:

> On Wed, Apr 09, 2008 at 12:12:54AM +0200, Daniel Stenberg wrote:
>> > Right, I can certainly see the point in supporting this. I think the real
>> > problem is that users can pass in anything in the quote commands, even
>> > commands that change states in ways libcurl doesn't track and thus cannot
>> > get out of after a failed command.
>
> But quote commands can already do that without even returning a quote error
> (e.g. -Q 'CWD foo'). If the application knows that its quote command
> could have harmful effects, it can simply call curl_easy_cleanup to
> force the connection closed when it sees the error code. If libcurl can
> assume that will happen, then it can freely reuse the connection even
> after such an error.

My reading of the curl_easy_cleanup man page makes me believe that it's too big
of a hammer for the job. It appears to make further use of the handle illegal.
  Unless I misunderstand, it seems that the cURL library user already has the
power to force a new connection by setting the value of the
CURLOPT_FRESH_CONNECT option.

On Wed, 9 Apr 2008, Daniel Stenberg wrote:

> Perhaps we should consider coming up with a way in which the application can
> mark commands as "kill connection when failed" or "connection is still fine
> when failed". Something like a prefix that can't be mistaken by an actual
> command?

In light of the CURLOPT_FRESH_CONNECT option, another option (or more command
syntax) may not be needed.

In my particular case, the quote commands tend to be queries rather than
directives that necessitate state changes, so failures tend to be benign. That
said, I think that your views of the more general situation are the proper
perspective.

Two Dans for the price of one! Thanks to both of you.

- Scott
Received on 2008-04-09