On Wed, 10 Dec 2003, Dave Meyer wrote:

> The exact match might not work all the time. Here's a few of the 350
> response codes that I've gotten from various servers:
>
> 350 Restarting at 2147483647. Send STORE or RETRIEVE to initiate transfer.
> 350 Will attempt to restart at position 2500000000.
> 350 Restarting at -1794967296. Send STORE or RETRIEVE to initiate transfer.
> 350 Restarting at 2500000000. Send STORE or RETRIEVE to initiate transfer.
> 350 Restarting at 50102
>
> (The last one was from the server that returned 501 for offsets above 2
> GB, by the way, hence the lower offset request.)
>
> It seems like we might just be able to skip the 350 and then start reading
> the next available number.

Right. It would probably also have a bigger chance of doing the right thing on
servers replying in different languages.

> Then it would be a pretty simple thing to see if it matched our request or
> not. Although I have no clue as to what the behavior of servers which
> report negative offsets would be. I guess it may not matter -- if the
> offset reported isn't the same as our request, we could just reset the
> request to 2 GB and ask again...

Well, it *might* be the same value we asked for, just treated as a signed
32bit value so that values between 2^31 to 2^32 create negatives. But I think
you're right, if the value differs from our requested value (be it negative or
not), we could start at the 2^32-1 point.

This made me think though. The libcurl interface allows the app to set a
RESUME_FROM point when doing a transfer. The application will then assume that
the transfer will be made from that point and onwards (or fail). We currently
have no means to pass back any feedback to the application that says "uh, we
had to start from point N instead of point X that you asked for"...

I'm not really sure how we solve this the nicest possible way...

> Also, any parsing like that would probably be best done by using the data in
> conn->data->state.buffer after the call to Curl_GetFTPResponse, correct? I
> see that done in a couple of other places...

Yes, inspiration for this parser can be found in the way we scan for the
download size in the 150/125 response after a RETR command.

-- 
    Daniel Stenberg -- http://curl.haxx.se/ -- http://daniel.haxx.se/
   [[ Do not send mails to this email address. They won't reach me. ]]
-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click