[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [bug-inetutils] ftpd returns 550 to NLST
From: |
Andrew Stevenson |
Subject: |
Re: [bug-inetutils] ftpd returns 550 to NLST |
Date: |
Wed, 13 Jul 2011 11:17:13 +0100 |
M E Andersson <address@hidden> wrote on 12/07/2011 22:53:38:
> onsdag den 6 juli 2011 klockan 21:25 skrev Andrew Stevenson detta:
>
> > If you NLST a non-existent file ftpd returns a 550 error. RFC 959 does
not
> > list 550 as a valid return code - IIUC the intended behaviour is to
return
> > an empty list.
>
> I disagree regarding the last claim, meaning I find the text
inconclusive.
>
> The text states 450 as the only allowed negative reply.
I was thinking of section 5.4:
NLST
125, 150
226, 250
425, 426, 451
450
500, 501, 502, 421, 530
The text suggests to me the section is supposed to be authoritative but I
may have got it wrong - I must admit I didn't read the whole document that
closely.
> However, the category 4xy is expressing a temporary condition like
> a busy or locked file. A message expressing a permanently missing
> file should be found in the message class 5xy. This was the path
> chosen by the original Netkit code and is presently continued also
> by GNU Inetutils. The FTP server of OpenBSD continues this design
> decision, as does linux-ftpd (available in Debian).
I do agree it seems more logical to allow 550 but 5.4 suggests to me you
can't. I'm no expert on this matter - I only came across it because I had
to debug a problem that turned out to be caused by an FTP client that had a
similar interpretation of the RFC (that 550 isn't an allowed response) - so
I'm happy to defer to others if they know better.
I'm also aware that the original BSD ftp code (and possibly all the current
BSD code) behaves the same. That's a good argument that the client should
probably be more generous in what it accepts but, if it is determined this
is incorrect behaviour, it probably isn't enough to justify keeping it in
the server, unless something widespread is relying on the behaviour.
Anyway I'm happy to defer to the wisdom of the list as to if people
consider this should be changed or not.
Thanks,
Andrew