On Wed, 3 Mar 2004, Eduardo =?iso-8859-1?Q?García?= wrote:

> >If that is the case, then I'd say that your server is doing it wrong. It
> >clearly responds with headers claiming to be a resumed transfer and it
> >identifies which part it sends. If that is not the right part, then your
> >server is behaving badly.
>
> It seems to be, but the server is a Microsoft-IIS/5.0 as you can read in
> headers. Standard enough for expecting correct behaviours, shouldn't it be?

*cough* *cough* Do you expect me to answer that question honestly?

> Well, as a matter of fact I have now also test to download a file on that
> server with IExplorer, SaveTargetAs...., unplug network cable, and plug it
> again after the error and repeat the download, IExplorer resumes the
> downloading at the unplug-point and gets an incorrect file as we get (the
> file restart at the resume point).

... which then is an independent indication that... tadaaaa, that web server
is bad. But I have no idea what kind of request IE sends in this case.

> Once you have downloaded the entire file (without errors), if you repeat the
> test, the results are completely different: nothing resumed if cache is
> disabled by request headers, and a perfect resume if cache is allowed. Don't
> you think there is something else masking the communication and its results
> ?

I'll admit I stopped once I noticed the obvious server-related problem of
yours. If the first stuff errors out because of silly server, how is
_anything_ range or resume related then supposed to work?

Also, I didn't quite understand which header log that was produced when
libcurl returned CURLE_HTTP_RANGE_ERROR since they all return 200 or 206 and
none of them should result in that libcurl error code.

-- 
    Daniel Stenberg -- http://curl.haxx.se/ -- http://daniel.haxx.se/
   [[ Do not send mails to this email address. They won't reach me. ]]