On Wed, 9 Apr 2008, Scott Barrett wrote:

>> 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.
>
> My reading of the curl_easy_cleanup man page makes me believe that it's too
> big of a hammer for the job.

Not only that. When the multi interface is used, a killed easy handle isn't
even a certain way to kill the connection (since the connection can be kept in
the multi handle to be re-used by a different easy handle) so it's not really
an approach to recommend.

> 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.

Yes, but to use that the application needs to have specific knowledge that it
really does not want to re-use an existing connection. In general that should
never be required as libcurl must only re-use connections it knows it can
re-use fine.

>> 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.

I disagree. The problem is not really when to start a fresh new connection but
to figure out when the connection is not fine to re-use. So we need a way to
know when the connection must not be re-used and we have way with current
libcurl to tell that dynamically. CURLOPT_FORBID_REUSE works, but then you
would have to tell that already before you start your transfer and for the
failed-quote-command case that's not really usable.

> 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.

Exactly, I realize that in your specific case libcurl isn't confused at all
and could re-use the connection fine. A generic approach that handles things
like RETR, STOR or similar (that might confuse things greatly) would be
diserable I think.

-- 
  Commercial curl and libcurl Technical Support: http://haxx.se/curl.html