lynx-dev
[Top][All Lists]
Advanced

[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


reply via email to

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