cURL / Mailing Lists / curl-library / Single Mail

curl-library

Re: libcurl not sending QUIT to terminate control connection

From: Daniel Stenberg <daniel-curl_at_haxx.se>
Date: Tue, 20 Jan 2004 09:07:31 +0100 (CET)

On Mon, 19 Jan 2004, Joe Halpin wrote:

> Ok, sorry to be so dense, I know everyone else here is busy too. I'm just
> not used to this development environment yet.

No worries. It's easy to help out and tell how we want things done, you're
doing the heavier job when you actually edit code! ;-)

> Anyway, I think I figured out most of the test stuff, and I'm attaching a
> patch for what I did. However, tests 304 and 505 keep failing and I don't
> see why. test304 is http so shouldn't be affected by a change to ftp.c.
> test505 output looks like it's correct to me.

First: thanks for your work on this, I believe this is a good move since it
makes libcurl behave more correctly using more kosher FTP speak.

Your patch showed a flaw in the diff/patch concept, as the lines with the QUIT
need DOS (CRLF) newlines (since I want the newlines verified too) and the
diff/patch tend to ignore the newlines and voila... I had to apply all those
QUIT lines manually! ;-( So, if you produce an updated patch, you can skip the
tests part!

Having passed that annoyance, I noticed you missed test case 130 to 134, but I
edited them as well and I too experience the problems on test 304 and 505.

Here's my analysis of the situation and my take on what to do about it:

The test case 190 really is the offender here. I believe curl's sending of the
'QUIT' is somehow in the pipe for the FTP server so when the sleep in test 190
is done, the FTP server stores QUIT in the proper file. This wouldn't be a
problem if the HTTP server didn't use the same file, and since test 190
already is passed when the FTP server stores this, it interferes with the
actual running tests: 304/505. This can be verified by running a lot of FTP
tests (except 190) and then test 304 and 505 and they will then run fine.

While this certainly identifies a minor flaw in the test suite's servers I
also think it identifies a flaw in how libcurl sends QUIT: if libcurl has
already deteced a bad situation we should not send the QUIT. If libcurl has
for example timed-out the response-reading of a previous command, it is really
stupid to issue another command! This calls for two things: 1) identify what a
"bad situation" is that would prevent a QUIT and 2) make sure that info/status
is passed on to the Curl_ftp_disconnect() function. I would say that changing
the function pointer prototype for protocol-specific disconnects might be the
nicest approach, or possibly by storing some ftp-specific info in the
ftp-struct. I'm open for ideas and suggestions on this.

(Also, do note that this patch will not be included in the 7.11.0 release due
for release any day now.)

-- 
    Daniel Stenberg -- http://curl.haxx.se/ -- http://daniel.haxx.se/
   [[ Do not send mails to this email address. They won't reach me. ]]
-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
Received on 2004-01-20