>> I would say that you should have a header callback and scan for the PASV
>> responses and if you get a "bad" one you disconnect that easy handle and
>> then redo that connection.
> is the CURLOPT_HEADERFUNCTION actually called for FTP replies? if so,
> maybe returning from there a CURLE_WRITE_ERROR and redoing both the
> colliding easy would work.
>
> with an additional CURLE_REDO_COMMAND, we could avoid trashing both
> connections (I fear that with a too simplistic solution I finish with
> something as slow as the trivial solution that i coded yesterday, i.e.,
> waiting first reception/emission before launching new request), we would
> trash only the pre-existing (because it is already trying to connect, and
> unfortunately it may have connected to the server side socket setup by
> second PASV command).
>
> It make me think that it would be rather cool to have a true handling of
> ABOR command, which would allow the actual explicit cancellation of an
> easy, -without- trashing the command connection. One way would be that
> when removing a ftp connection from a multi, and this ftp connection is in
> the middle of data stuff, we could issue a ABOR command, note that we may
> have to trash [426] 226 response(s) if it is actually reused.
>
> In fact the problem with fully trashing/redoing a connection is that it
> costs me a minimum of a dozen of additional lags if not twenty (with
> proxy/ssl stuff), while a normal download costs around 4, redoing both
> PASV would costs 4 lags (+2 for ABOR).
any remark about this?

can/should I implement the ABOR command? (which could be used by the way to
handle properly the cancellation of a command)

Armel
Received on 2006-09-11