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

Armel
Received on 2006-08-25