Re: FTP Extensions for Cryptographic Hashes (draft-bryan-ftp-hash)

[Tim Kosse <[e-mail]>]

On 2010-03-24 22:59, Daniel Stenberg wrote:
> You use 550 as response code when the user isn't allowed to use the HASH
> command, but I find that 550 is otherwise often used for file-not-found
> in both SIZE, RETR and other responses.

It is very common for servers to return 550 for "Permission/access
denied". Even RFC 959 gives an example with a "550 Access denied" reply
to STOR.

Also, RFC 3659 states that a 550 reply to SIZE "MUST NOT be taken by the
client as an indication that the file cannot be transferred [...] A
server may generate this error for other reasons [...]"

> Wouldn't it make sense to have a "file not found" response for when you
> try to HASH a non-existing file? Wouldn't it make sense to re-use the
> same error code (550) for that as other command use?

Yes, for "file not found" 550 should be used.

> Maybe the "HASH not allowed" case can use 552 or 553?

If I interpret RFC 959 correctly, 550 should be used for all errors not
having a dedicated 55z reply code. It gives 552 as "Exceeded storage
allocation" and 553 as "File name not allowed". That pretty much rules
out 552 for "permission denied" and 553 does not seem fitting either.

So I would just use 550 for both "File not found" as well as "Permission
denied".


Frankly said, I doubt that FTP clients would even care about a
difference. It's possible to create FTP clients that only care about the
first digit of a reply, whereas a person would always look at the text
and not the exact code.


Regards,
Tim Kosse