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

[David Woolley]

> 
> [ S->C ] 200 PORT command successful.
> 
> [ Note to WU-FTPD Development Group: As I've noted before, we should be
>   establishing the data connection at this point. ]

This is not what RFC 959 says:

      (local pathname) test 1 <CR>   User-FTP opens local file in ASCII.
      (for. pathname) test.pl1<CR>   RETR test.pl1<CRLF> ---->
                                     <---- 150 File status okay;
                                           about to open data
                                           connection<CRLF>.
                                     Server makes data connection
                                     to port U.
Also:
         A->C : 227 Entering Passive Mode. A1,A2,A3,A4,a1,a2
                                           C->B : PORT A1,A2,A3,A4,a1,a2
                                           B->C : 200 Okay
         C->A : STOR                       C->B : RETR
                    B->A : Connect to HOST-A, PORT-a

> 
> 08:58:26.370766 ftp.wu-ftpd.org.14446 > ftp.wu-ftpd.org.ftp: P 78:86(8) ack=
>  590
> 
> [ C->S ] RETR /
> 
> [ Note to Lynx developers: Be glad we're not yet up to snuff on RFC complia=
> nce
>   at this point in the conversation.  You have issued a RETR.  That command,
>   failed or not, means the server should close the data connection.  As a P=
> ORT
>   mode connection, a compliant server would re-open the same source/destina=
> tion

Only if it has opened it, but the sample event sequences in RFC 959
indicate that it won't have opened it at that point.

>   pair should you issue another RETR, which you're about to do.  This will
>   probably fail since the client end will be refusing that pair for a while
>   longer yet.  If you're used a PASV mode connection, the server would still

That's more of a problem, because some of the scenarios allow a race
condition during a third party operation.  It looks to me that RFC 959
hasn't properly defined the error recovery where there is a race and
has specified parallel operation, where issuing the command to the
passive side before the active side would be safer, as it would allow
a backout before the the connection was made if either party was
unwilling.

>   have closed it at this point, and fallen back to the default, PORT mode ..
>   lacking a port number for the client end, the server would refuse all
>   subsequent data transfer requests until another PASV, or a PORT command, =
> is
>   received. ]

I can see nothing that would indicate that PASV mode should be cancelled
at this point; it just happens that most clients issues PORT and PASV
redundantly.