Re: lynx-dev rfc959 problem...

[Klaus Weide]

On Sun, 27 Feb 100, T.E.Dickey wrote:
> > On Thu, 24 Feb 100, T.E.Dickey wrote: 
> >  
> > > trying to download this: 
> > >   http://www2.wku.edu/scripts/fileserv/fileserv.com?NETLIB022 
> > >  
> > > fails - I get 6Kb completed before the "QUIT" which is issued right after 
> > > the listen succeeds catches up and makes the server stop sending. 
> > >  
> > > btw - that doesn't seem to happen through a firewall (I tried testing it 
> > > at work, to verify, and it worked there, but not from here). 
> >  
> > That is an HTTP URL - what does it have to do with the FTP protocol 
> > (RFC 959)? 
> 
> that's a download page for the file I was interested in.

I see - sorry, I had overlooked the link.

I get the same problem, with my current dev.18-based code (some changes
from dev.18, but none in HTFTP.c or HTTCP.c).  So it doesn't seem to have
been introduced after dev.18.

It seems that the server is violating the FTP protocol.  It should not
immediately react to the QUIT, but just queue it.  The server seems to
treat the QUIT like an ABOR instead.

OTOH, I now find that sending the QUIT at the point where Lynx now does
it may not be correct either...  I find RFC 959 ambiguous where it says

            1yz   Positive Preliminary reply

               The requested action is being initiated; expect another
               reply before proceeding with a new command.  (The
               user-process sending another command before the
               completion reply would be in violation of protocol; but
               server-FTP processes should queue any commands that
               arrive while a preceding command is in progress.)  [...]

(Does "would be in violation" mean "is in violation" or not?)

This looks similar to the problem Henry reported recently (but I
couldn't reproduce it in his case).

(1)The reason for sending QUIT at all (which didn't happen at all in
previous versions), rather than just closing the connection, was
to close the connection "cleanly" and avoid a complaint from (at least)
wu-ftpd (which resulted in unecessary RST traffic).

(2)The reason for queueing the QUIT, rather than sending it after the
successful data transfer, was to avoid another full round-trip time -
just a bit of optimisation.

Since it turns out that this doesn't work with all servers - the
easies way to make it work would probably be to just remove the two lines

    if ((status = send_cmd_nowait("QUIT")) == 1)
        outstanding++;

(untested).

That should work, but it would be nice to then add a send_cmd_1("QUIT")
instead of those lines, at least after a successful transfer; probably
right before the NETCLOSE(control->socket); for objective (1).

   Klaus