Re: lynx-dev RFC959 non-compliance in Lynx hangs the client

[Klaus Weide]

[ Going back to the initial message in this thread ]
Ok, I went through RFC 959 to check.  Various comments based on that:

On Tue, 7 Sep 1999, Gregory A Lundberg wrote:

> The WU-FTPD Development Group is in beta test for version 2.6.0 of the
> WU-FTPD daemon.
> 
> One change in this version improves RFC compliance on the server side.  In
> particular, what we're doing is enforcing a clean shutdown of the data
> connection prior to sending the 2xx Transfer Complete message on the FTP
> control channel.

Well, lynx may have been doing the wrong thing.  The closest statement
in the RFC I could find that requires the behavior you expect is:

[ 5.2.  CONNECTIONS ]
      Any time either the user or server see that the connection is
      being closed by the other side, it should promptly read any
      remaining data queued on the connection and issue the close on its
      own side.

Note that it's a "should", and to me it sounds more like a general
exhortation than a protocol requirement.

I do not think that your change is one that "improves RFC compliance on the
server side."  For the server, the most relevant statements seems to be:

[ 5.2 ]
      The data connection shall be closed by the server under the
      conditions described in the Section on Establishing Data
      Connections.  If the data connection is to be closed following a
      data transfer where closing the connection is not required to
      indicate the end-of-file, the server must do so immediately.

[ 3.2  ESTABLISHING DATA CONNECTIONS ]
      In general, it is the server's responsibility to maintain the data
      connection--to initiate it and to close it. [...] The server
      MUST close the data connection under the following conditions:

         1. The server has completed sending data in a transfer mode
            that requires a close to indicate EOF.

         2. The server receives an ABORT command from the user.

         3. The port specification is changed by a command from the
            user.

         4. The control connection is closed legally or otherwise.

         5. An irrecoverable error condition occurs.

[Point 5 confirms part of what you said about lynx's use of PORT.]

Point 1 is the case we are concerned with.  The server "MUST close",
but nowhere is it said what exactly is part of that "close".  In
particular it is not required explicitly to wait for the client side
close.  It isn't far-fetched to assume close is meant here to behave
as close() with normal socket behavior (without SO_LINGER etc.).
So I don't think the claim is right that this makes the server more
compliant.  It may require more compliant behavior in one respect
from the client (if the "should" sentence above is regarded as a
protocol requirement), but that's quite a different thing.

> This change was made in support of non-compliant FTP
> clients which take receipt of the 2xx Transfer Complete message literally.
> Since this message is sent via the control connection, even though it is
> sent by the server after the final data has been sent via the data
> connection, there is no guarentee it will arrive at the client host after
> the last data-connection packet.

So here's the real reason: those other unnamed clients which are much
more definitely broken.  (For one thing, lynx at lest clearly hangs;
form your description it sounds like those clients could artbitrarily
lose data at the end of files and this loss would go unnoticed.)

[ It seems likely you are talking abount clients programmed for a
  platforms that makes threading just too easy for the programmer's
  own good... ]

> To date, we have found only two FTP clients which have a problem with this
> change.  Obviously, Lynx is one of them.

Well, you are carefully saying that lynx is non-compliant or broken, you
only say you found a problem. :)

Obviously I don't agree with the trade-off you are making, between support
for *those* kinds of clients and *this* client.  While my patch should
solve the problem for the future (if it doesn't cause some weird reaction
from some unusual server out there), the WU-FTPD change obviously breaks
interoperability with the installed base of clients.  So I hope you
can find a way around this.  (I guess in HTTP one would use User-Agent-
based exceptions...)

   Klaus