Re: [ftpext] Fwd: New Version Notification for draft-bryan-ftp-range-06.txt

[Tim Kosse <[e-mail]>]

On 2012-06-05 01:53, Anthony Bryan wrote:
> FYI, any comments?
> http://tools.ietf.org/html/draft-bryan-ftp-range

> 3. octet Ranges in STREAM Mode

The title of section 3 should probably start a capital letter.

>    The server-PI SHOULD transfer the whole range from the start point to
>    the end point with RETR if the end point is larger than the actual
>    file.

Seems unclear, in particular what to send between the end of the file
and the end point. I suppose you meant the following?

The server-PI SHOULD transfer the whole range from the start point to
the end of the file with RETR if the end point is larger than the actual
file.

> With STOR, however, the server must
>    insert the data into the file named.  The results are undefined if a
>    client uses RANG to do other than restart to complete a transfer of a
>    file that had previously failed to completely transfer.  In
>    particular, if the restart marker set with a RANG command is not at
>    the end of the data currently stored at the server, as reported by
>    the server, or if insufficient data are provided in a STOR that
>    follows a RANG to extend the destination file to at least its
>    previous size, then the effects are undefined.

The requirement of the start point to be at the end of the file if used
with STOR is problematic.

If a transfer is interrupted due to a network error, it can happen that
the for the client the transfer has failed already whereas the server
things it is still ongoing. If there is data still in-flight or
otherwise pending, the file size can change between the call to SIZE and
the subsequent RANG/STOR. Only workaround would be for the client to
wait an unspecified time before resuming until it can be reasonably sure
that there is no pending data still in-flight.

I would change the semantics as follows:

- The RANG start point must never exceed the file size
- If it is less than the file size, continue writing at that position in
the file, overwriting existing data between start-point and end-point.
- RANG must not cause files on the server to be truncated
- Implementation note: Some servers currently open the file with
O_APPEND if using STOR, they should not do this anymore.

Apart from solving the timing issue, this change would also makes it
possible to selectively modify parts of a file on the server.

Regards,
Tim