libURL issues?

[Dave Cragg]

At 4:38 pm -0600 27/1/04, Chipp Walters wrote:
>Richard,
>
>I mentioned this at the conference.

I knew there was a reason I should have had my fare paid. :)

>libURL thinks it's got the file, but it's not *the* file. Just a small bit
>of nodata it thinks is the file. IMO, it has to do with latency. My DAD has
>this problem with his ISP: starband.net (bigtime latency).

I don't know if this was the problem Richard was having, but I just 
recently got a report of something similar. But only when downloading 
from IIS ftp server, and only with the Win32 engine. Does that match 
your experience?  (There had been other similar problems with engine 
versions prior to 2.4.3, but most seem to have been cleared up.) The 
problem seems to occur with very fast transmissions such as when the 
server is on the same machine as the client, or over very fast 
networks.

But from what I found, the socketClosed message was sent prior to the 
final dribble of data being read from the socket. And this only 
occurred when the final chunk of data was fairly small (and even then 
it didn't always happen). So most of the file has been collected, 
which doesn't match your "small bit of nodata".

Unfortunately, with ftp, the socket closing on the data transfer 
connection is the signal that the transfer has completed. So libUrl 
is trusting the socketClosed message.

If something similar happens with http, libUrl will return an error 
that the socket closed prematurely. (Unless the server doesn't 
include a Content-length header or doesn't use the "chunked" transfer 
method. Again, IIS can be a problem here, especially with some CGI 
scripts if the script doesn't add a Content-length header. Apache in 
these cases will use the "chunked" transfer encoding which lets the 
client know it has got all the data.)

Cheers
Dave