bug-inetutils
[Top][All Lists]
Advanced

[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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]