On Thu, 5 Sep 2002, Roth, Kevin P. wrote:

> I've tried with version 7.9.8, in both cygwin and win32 flavors. I've also
> tried the cygwin flavor of 7.10-pre2. All of the above exhibit exactly the
> same behavior. I've also tried with and without the --trace feature
> enabled.

Disturbing news indeed.

> I'm trying to download a .ZIP file, which is being returned from an ISAPI
> extension (.dll) under IIS 4. The server is out of my control so I can't
> easily duplicate the issue. I tried placing the .ZIP file on my own IIS 4
> web server (not getting it through the internet or from that .dll) and it
> works fine.
>
> I can download this file properly using Internet Explorer, so the web
> server is not simply skipping pieces.

Can you run ethereal or some other network analyzing tool to see how the data
looks on the network?

I mean, if you can repeat this at will that is.

I mean, this being TCP we can't possibly just not get the data, it really
need to be lost within curl for this to happen. A network dump of a download
with curl compared to one with IE would prove this.

> I've tried using the --http1.0 flag (actually I used -0) to disable
> http/1.1. Same problem still.

Yes, there's a very little internal difference between 1.0 or 1.1 so it
doesn't really surprise me.

> The .ZIP file is supposed to be 69,147 bytes long. But the file I get back
> from curl is only 52,447 bytes long. The difference is 16,700 bytes.
>
> Here's what the command line looks like:
> $ curl.exe -v -O -A "Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0)" \
> -b "cky.txt" -0 --trace trace.log \
> "https://-------.----.---/cgi-bin/HttpDownload.dll/Session_detail2002_07.zip"
> % Total % Received % Xferd Average Speed Time Curr.
> Dload Upload Total Current Left Speed
> 100 52447 0 52447 0 0 18913 0 --:--:-- 0:00:02 --:--:-- 30652
> curl: (52) Empty reply from server

The fact that this says "Empty reply from server" is really silly, but I
think that is an unrelated bug (and I believe I might have a fix for this
soon).

> I compared this partial file with the real thing, and discovered that the
> FIRST 16,700 bytes were missing, rather than the last...

What if you use -i when getting the file, do you get all the headers fine
then but miss the first 16,700 bytes of the data?

[the end of the request]
> 00c0: 69 6d 61 67 65 2f 70 6a 70 65 67 2c 20 2a 2f 2a image/pjpeg, */*
> 00d0: 0d 0a 43 6f 6f 6b 69 65 3a 20 55 73 65 72 4e 61 ..Cookie: UserNa
> 00e0: 6d 65 3d 4d -- -- -- -- -- -- -- -- -- -- 0d 0a me=-----------..
> 0180: 0d 0a ..

[the first data received]

> <= Recv data, 7876 bytes (0x1ec4)
> 0000: 36 2a 68 ce 02 2b c1 2d f0 c9 4a 93 ad 80 17 98 6*h..+.-..J.....
> 0010: a3 6d 87 97 f4 26 fb dc 4b a6 1d e3 f9 8e 41 2e .m...&..K.....A.
> 0020: a0 32 7e ca 51 d3 c3 56 67 e0 90 7a fa c7 f3 b9 .2~.Q..Vg..z....

I guess this answers my previous question. You don't seem to get any headers
in your trace dump, and that is certainly very weird.

Well, apart from single-stepping throgh the code with a debugger to figure
out where it goes wrong (from the select() in lib/transfer.c:Transfer() and
onwards), I don't have many good ideas right now.

-- 
 Daniel Stenberg -- curl related mails on curl related mailing lists please
-------------------------------------------------------
This sf.net email is sponsored by: OSDN - Tired of that same old
cell phone?  Get a new here for FREE!
https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390