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

[Klaus Weide]

On Fri, 10 Sep 1999, Gregory A Lundberg wrote:
> On Fri, Sep 10, 1999 at 03:38:18PM -0500, Klaus Weide wrote:
> 
> > > Any client which issues a PORT command but is not ready to accept the
> > > connection is hopelessly broken.
> > 
> > How many clients do you know that are hopelessly broken according to this
> > definition?  How many that are not hopelessly broken?  
> 
> No, I meant being ready to have the initial triple-handshake occur at any
> time after sending the PORT; 

Ok

> which to me means having created the socket, bound it if needed, and
> issued an accept.

Not exactly; we have to have called socket() and bind() in order to know
what to put in the PORT command.  There's no need to have called either
listen() or accept() at that point.  Calling listen() just has to happen
somewhere before sending the RETR or LIST or other command that would
actually make the server open the data connection.  RFC 959 3.2:

      The passive data transfer process (this may be a user-DTP or a
      second server-DTP) shall "listen" on the data port prior to
      sending a transfer request command. [...]       The server, upon
      receiving the transfer request, will initiate the data connection
      to the port.

We can (and lynx does) defer the accept() until we see a response to
the transfer request on the control connection.  I see nothing wrong
with that (apart from the question what to do if that response is not
1zy).  If any of this is wrong, please correct me.

If we had to issue an accept before we can send the PORT command
or the transfer request, we would have to use non-blocking sockets
and select.  Nothing in the FTP spec seems to require that, not even 
for servers.

Deferring the listen() and accept() until after the PORT, one (application
or stack) has to do slightly less cleanup work if the PORT itself doesn't
return a successful status message (a faint possibility?)

> Every client I've ever tested was capable of establishing the data
> connection when it issued the PORT command.  

YM "when" = "possibly after, but before the next command", I assume.

>                                             Which makes sense, since you'd
> have to go through the work before sending the command in order to have the
> proper port number.
> 
> I'm sure one could postulate an implementation which selected the port
> number in the application, and sent that port number in a PORT, but had not
> yet initialized the TCP stack to a point the connection could be
> established.  I've never seen one.  

That seems to describe the state where bind() has been called but listen()
hasn't.  Doesn't look that exotic to me, am I missing something?

  Klaus