> Please keep that patch separate from the big file support. It will make
> it easier to test and work on them separately. I assume that you will
> only do the response parsing if the REST value given is larger than
> 2GB? That will address the concern previously posted by Dominick
> Meglio.

Actually I was referring to something different. There may be instances
where even if it is a >2GB file that you do NOT want this feature. The way
he said he was going to implement it was to search for the first number in
the 350 response. Ok, I'm not an expert on FTP, but to my knowledge, there
really is no standardized format for the text of a response code. But in any
case, I'd say in 99% of the cases, what he stated will work. But what if the
reply were:

350 Restarting at 3,000,000,000. Send STOR or RETR

If he simply searches for the first number, that means he is going to begin
at byte 3 which is clearly not what that message intends. And of course
simply saying "well I'll make it skip ," isn't a good fix either because in
some countries they use a . for a thousands-seperator. And I'm sure in other
parts of the world there are even other characters. Now you're probably
wondering why would a server do that? But, as far as I'm aware, the text of
a response code is simply for the user to read. Using "3,000,000,000" makes
it much clearer to the user that the offset is ~3G than does "3000000000"
which is harder to read. My point is simply that parsing a text string that
has no specified format such as this can lead to the possibility that there
is some server out there on which it will not work.

Of course if I'm wrong about the fact that the server can use whatever text
string it wants, then my argument falls apart. But I read over the draft
defining the REST command and all it says about the message is:

The server-PI will respond to the REST command with a 350 reply, indicating
that the REST parameter has been saved, and that another command, which
should be either RETR or STOR, should then follow to complete the restart.
(draft-ietf-ftpext-mlst-12, Section 5.3). It also defines the format for the
message as follows:

rest-response = "350" SP *TCHAR CRLF / error-response

From that it seems as though there is no requirement on how the offset
should be formatted. Hence the CURLOPT_ for it. In case the libcurl user
happens to be on a server that uses some odd message (and we really can't
rule out that such servers exist), they are still able to correctly deal
with the REST command.

Dominick Meglio

-------------------------------------------------------
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
Received on 2003-12-16