Daniel Stenberg wrote:
> On Mon, 19 Jan 2004, Joe Halpin wrote:

[...]

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

Sounds like a "bad situation" would be for any previous I/O operation to
have encountered an error. In that case, it seems like the previous
operation should have the side effect of recording the failure somehow.

If we want to consider that any failure is a show-stopper, one
possibility is that we could add a flag to the FTP struct that says
whether or not the connection is still valid. Anything that does I/O
would need to check this flag.

That sounds like too much work and too much of a maintenance problem to
me. I'm not sure I understood what you meant by "changing the function
pointer prototype" though. If you're talking about changing the pointers
so they invoke error handling routines rather than doing I/O, that
sounds good to me as well. We might have to call exit() in there
someplace though.

I'll try to get more familiar with the code and see if I can figure out
a good way to do this.

Joe

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