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: Tue, 7 Sep 1999 20:15:12 -0500 (CDT)

On Tue, 7 Sep 1999, Gregory A Lundberg wrote:
> On Tue, Sep 07, 1999 at 11:31:07AM -0500, Klaus Weide wrote:
> 
> One comment here, having glanced through your patch:
> 
>   You should not depend upon ANYTHING in the response code, other than the
>   first digit.

I don't think the lynx code is more specific than necessary; in general
only the first digit is checked (and often jsut whether it's different
from '2').  Some codes are specifically defined for the server to
signal that it is closing the control connection.  Reacting specially
to those is just to avoid waitnig for replies that aren't gonna come
(maybe avoiding some other kind of hang).  Then there's one or two cases
of specific checks for workarounds for specific servers.  That's my
general impression without having checked everything in detail.

But thanks for the warning anyway.

>   A server SHOULD send the recommended codes in response to a command.  A
>   server MAY send any response; including one with an unrecognized first
>   digit.

Well it seems that wouldnt be an FTP server compliant to RFC 959 then:

 [ 5.4 ]
      The table below lists alternative success and failure replies for
      each command.  These must be strictly adhered to; a server may
      substitute text in the replies, but the meaning and action implied
      by the code numbers and by the specific command reply sequence
      cannot be altered.

>   For example, while the recommended response at the end of a data transfer
>   is 226; the server could send anything from 200 through 299, inclusive,
>   to answer the command.  

It should at least not send a code that is defined to mean one thing in
the RFC (for example that the data cor control connection has been or
will be colsed) when in fact that's not true.

>                          A well-written client will see them all as a
>   positive response to the command and continue processing.

In general I agree.

>   In addition, a well-written client SHOULD be able to process any
>   unexpected response.  For example, RFC959 does not specify that a 5xx
>   code might be sent at the end of a data transfer.  If a server chose too,
>   however, the client should recognize the error as a permanent failure and
>   terminate processing the current command sequence.
> 
>   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.

>   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.

> There is a comment there that Lynx is making an invalid assumption about
> the way the PORT command works.

Yes, I see what you mean...  Do you kown of any real-life servers that
are strictly compliant in this respect?

It sounds like a pain to deal with.  I bet you woud discover more than
two clients that have problems with that...

> The traced Lynx session attempts a PORT/RETR/CWD/LIST sequence.  This
> should be PORT/RETR/CWD/PORT/LIST since the server SHOULD open the data
> connection immedeately upon receipt of PORT, and SHOULD close that
> connection after any transfer command, regardless of the success or failure
> of that command.

Shouldn't we have to accept() the first connection too?  (Just to drop
it immediately, I guess.) What if we don't know whether the server behaves
"normally" or "strictly".  (No I haven't thought this through.)

[...]
> If you try against ftp.wu-ftpd.org and see a directory listing, I'd say
> you're doing well.  If you can actually view a README file, you're fixed.

It seems for file transfers lynx was already doing the data close
immediately after the EOF (in the normal successful case at least).
That probably means my patch won't create any problems, since it
just does the same for directory requests.

   Klaus


reply via email to

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