[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: 2.8.3dev.8 patch 3 (was: lynx-dev RFC959 non-compliance)
From: |
Klaus Weide |
Subject: |
Re: 2.8.3dev.8 patch 3 (was: lynx-dev RFC959 non-compliance) |
Date: |
Fri, 10 Sep 1999 14:27:04 -0500 (CDT) |
On Wed, 8 Sep 1999, Gregory A Lundberg wrote:
> RFC 1123 ammends RFC 959:
Thanks for pointing that out. I was aware that it updates requirements
for various protocols, but didn't think of it here.
> 4.1.2.11 FTP Replies: RFC-959 Section 4.2, Page 35
>
> [...]
> A User-FTP SHOULD NOT interpret a 421 reply code ("Service
> not available, closing control connection") specially, but
> SHOULD detect closing of the control connection by the
> server.
The lynx code seems to violate this one. I think in the case of lynx
(or generally web browsers) this is acceptable. We wouldn't keep the
connection open anyway after a successful request, so believing the
server in this case doesn't change anything significant.
> > > The RFC does not lay out how to handle [6-9]yz responses. MY
> > > reccomendation, based upon usage in FTPSEC and other RFCs, is to
> > > treat these the same as 2yx .. final positive response to the
> > > previous command.
> >
> > Do you have some specific pointers? Treating arbitrary [6-9]yz as 2xy
> > doesn't sound like a safe thing (without knowing anything about how they
> > _are_ being used by protocol extensions). The alternative (below) seems
> > like the safe choice.
>
> The intention is that a client could be used to carry out a conversation
> using commands and replies for which it has no specific knowledge. Some
> controlling entity would know the commands and interpret the replies.
>
> > > It would ve valid for a client, however, to treat these as non-protocol
> > > replies and immedeately terminate the entire session as not being FTP.
>
> Such a client would probably not be usable for any extended FTP features.
>
> Given the nature of web browsers, which are intended solely for human use
> and are rarely, if ever, usable by automata, walking away from the entire
> problam is a valid choice.
>
> Or, at least, this was the case. If we consider the effect of client-side
> Java scripts, continueing the FTP conversation may indeed be the correct
> choice.
This doesn't apply to lynx, so "walking away" seems perfectly reasonable.
I would hope such extended features are designed in such a way that the
server will refrain from sending [6-9]yz codes in response to "normal"
commands (without prior negotiation).
Klaus
Re: lynx-dev RFC959 non-compliance in Lynx hangs the client, Klaus Weide, 1999/09/07