>
>> Any idea to help me debug this one?
>>>
>>
>> The ftp_state_get_resp() function should check if there is more data in
>> the line buffer to read than the 150/125 code it got, and in that case it
>> needs to keep reading the entire coming response before it goes on.
>>
>>
> 425 code seems to be trashed already when this function is called. It
> looks to me that ftp_readresp() function should read all lines from the
> control connection and return the latest code -in this case 425- and no
> attempt should be made to allow server connect. This approach fixes the
> case happening in below order.
>
>
With better debugging, it looks nothing is trashed. The remaining of input
is kept in pingpong structure (pp->cache) of the connection. Checking the
cache size and reading server response once more allows to appreciate 425
and take the correct action and handle below case.

> <150 -> Handled
> <425 -> Disposed
> AllowServerConnect -> Waits forever
>

> But does not handle the case (reported in the bug mentioned) happening in
> below order. This needs monitoring of control channel (as well as data
> channel) as you have pointed out.
>

The case below however requires monitoring of both control and data
connection via poll...

>
> <150
> Curl calls AllowServerConnect
> <425
>
> Any general solution suggestion?
>
>
> Thanks.
>

-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2011-12-01