Re: 2.8.3dev.8 patch 3 (was: lynx-dev RFC959 non-compliance)

[Gregory A Lundberg]

On Tue, Sep 07, 1999 at 11:31:07AM -0500, Klaus Weide wrote:

> Below is a patch for the most recent lynx development code (2.8.3dev.8).
> Most of it is stuff that I had already done before your message and was
> planning to send to lynx-dev.  Among other things, one major purpose was
> ending the control conversation cleanly, at least in the normal case, to
> get rid of the "221 You could at least say goodbye.." responses from
> wu-ftpd servers and resulting RST traffic.

One comment here, having glanced through your patch:

  You should not depend upon ANYTHING in the response code, other than the
  first digit.

  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.

  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.  A well-written client will see them all as a
  positive response to the command and continue processing.

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

> I haven't looked closely at the traffic traces and assorted comments in
> the other message yet.

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

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.

You sequence is valid, but would likely either fail or cause a very long
pause.  The reason is the port pair involved in the failes PORT transfer
will be rejected by the client's TCP stack for some time following the
closure.  The server SHOULD retry that pair, but for all practical
purposes, we know it will fail.

For PASV transfers, you MUST reissue the PASV command.  The server should not
be expected accept a re-connection attempt on the PASV port, and most
likely will fall back to the most-recent PORT (if one was issued) or simply
fail the command as not having any data connection available for the
transfer.

> Could you please try lynx with this patch.

I'll give it a shot, but I've found Lynx to be singularly difficult to get
to behave (mutt was much easier).  The only versions I've been able to
semi-use (and those not to well) are the official Redhat versions .. even
with them , the screen display is often messed up and unreadable.  Luckily,
I'm an FTP geek and rarely go to the web. :P

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.

-- 

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

pgpCSXz6m2xGy.pgp
Description: PGP signature