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

[Gregory A Lundberg]

On Wed, Sep 08, 1999 at 08:32:53AM +0100, David Woolley wrote:

> > [ C->S ] RETR /
> 
> This should only actually happen when a semantically broken URL is
> used.  Correctly formed URLs never result in /s being sent to Unix
> servers, as they are always implemented by stepping one directory
> at a time from the login directory.  Forcing a / into the URL is used
> for broken servers or to work round incorrectly specified URLs.  If
> you didn't force in the initial /, then Lynx has a real problem.
> 
> Lynx will be doing an RETR here because it doesn't know that the
> initial, forced, / is a directory.  The CWD is actually error
> recovery in Lynx.

Well it should.  That is, if you're reading the RFCs.

I _could_ implement this.  What do you think Lynx would do if I sent you a
tarball?  It is a valid response to your request.  Or I could send you a
directory listing, also a valid response.  But I think I'll be nice .. on
the data channel I'll send you an empty file; and on the control channel,
I'll send you an error reply.  Why?  Because, while I could do a lot of
other things, I know a request to retrieve a directory is probably a
mistake on your part.

> >   mode connection, a compliant server would re-open the same source/destina=
> > tion
> >   pair should you issue another RETR, which you're about to do.  This will
> 
> I suspect the reality is that most servers don't actually open the connection
> until they receive the RETR etc.  I'll take your word for it that the
> RFC is well defined in this case, but most API specs I've seen tend not
> to fully specify the system state after an error return.

In reality, no.  But most servers have not upgraded to the latest RFCs,
either.  In fact, most servers are based on the RFC 765 implementation in
the final release of BSD.  Well, they would be, but most well-managed sites
upgrade to wu-ftpd.

The fact remains, the server SHOULD open the PORT connection immedeately
upon the receipt of the command.  As a client author, you are expected to
see that means you MUST be prepared to accept a connection at any time.

Any client which issues a PORT command but is not ready to accept the
connection is hopelessly broken.

Your failed RETR / is an unrecoverable error.  The server SHOULD close the
connection due to that error (if it has one open).  As a client author, you
are expected to see that:

 - the server might never have openned the connection, in which case your
   reading of the RFC leaves the state of the port selection undefined.  No
   problem .. if you don't know what the state is, how do you reset it to a
   known state?  By sending a PORT or PASV command, of course!

 - the server might close the connection, in which case you need to have it
   open another by sending another PORT or PASV command.  (Well, the server
   could try to reuse the ports, but we know CLOSE_WAIT state of the TCP
   will causes problems there for most IP stacks.  Avoid the problem, send
   another PORT or PASV command.)

 - the server might not close the connection, in which case you have a
   choice:

   - you could declare the server hopeless and walk away (like IE would).
     This would generate complaints to you and there server author.  It is
     an easy first-choice and many take it until they learn better.

   - you could attempt to go on with the existing connection.  This is also
     an easy choice.  In fact, noone may ever notice you took it, unless
     also fail to handle the case where the server closes the connection ..
     oh .. wait a minute .. isn't this what this whole thread is about?

   - you could try to convince the server to do the right thing by
     sending another PORT or PASV command.  If the server _still_ does not
     close the data connection, it *IS* hopeless, so you should walk away.

The only solution from the above is to send a PORT or PASV command before
every data transfer command.  All other choices lead to future problems.

The only failing I see is the RFC presumes the reader is an experienced
programmer/analyst and can see this logic on his own.

-- 

Gregory A Lundberg              WU-FTPD Development Group
1441 Elmdale Drive              address@hidden
Kettering, OH 45409-1615 USA    1-800-809-2195

pgpIcCvqFcZ6X.pgp
Description: PGP signature