On Tue, 29 Nov 2011, Gokhan Sengun wrote:

>
> when server replies with
>>
>> 150 Opening data channel for file transfer.
>> 425 Can't open data connection.
>>
>> Most of the time, curl is disposing message 425. I have not debug it yet
>> so do not have an idea who eats the message.
>>
>
> It happens because libcurl will read whatever the server sends, and that
> may very well be more than just "a line". libcurl itself doesn't even have
> a concept of lines until it parses what it has received over the network.
>
> So libcurl probably read both lines at once, and then it parsed just the
> 150 line before it went waiting for the server to connect. If it had just
> "peaked" beyond the 150 line in the buffer it already has, it would've
> found the 425 status.
>
>
Debugging confirms what you have written here.

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

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

<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-11-30