RANG: RETR, STOR, APPE errors for incorrect ranges?

[antbryan]

"there isn't anything to state what errors are given by RETR if the range specified is incorrect, or by STOR / APPE if the range specified starts more than one byte after the end of the existing file on the server (and therefore, presumably, incorrect?)."

[antbryan]

from ftp list:

"I think it should be documented that the server must fill the gap with nul bytes,
with a note that it may use it as a hint to do that using a sparse file."

[tatsuhiro-t]

It seems we described that STOR with RANG starting after the actual file size is error:

The server-PI should reject the STOR if a client issues a RANG with a
start-point greater than the actual file size. If the start-point is
less than or equal to the file size, the file is opened for writing,
continuing at start-point.

Do you think it is better to allow zero-fill for this case?
Personally I'm OK with this, but not so strongly.

For the error code, we only defines in 500, 501 for RANG command itself.
The reviewer said about the error code of RETR.
RFC 959 lists possible error code for RETR in a cryptic way:

           RETR
              125, 150
                 (110)
                 226, 250
                 425, 426, 451
              450, 550
              500, 501, 421, 530

Should we pick some code from this or just state that error code from RETR is subject under RFC 959
(so basically loosely defined)?

[antbryan]

good question, wondering if it might be better to separate RANG and RETR/STOR/etc_with_RANG into 2 separate drafts (issue #15). because RANG is basically done minus this issue and that's what HASH is - a separate draft that happens to use RANG.

[tatsuhiro-t]

It certainly speeds up RANG draft, but I wonder the implementors cannot write code with only the RANG draft, no?

[antbryan]

it would be like HASH which depends on RANG. they would all progress together in a cluster & be finalized together.

someone might want to support RANG with HASH but not RANG with RETR/STOR or the other way around.

[tatsuhiro-t]

OK, understood. That would make things forward.