How did you output the request header?

I just issued the command...
curl -i -D header.txt -C 3715816
http://homepage.mac.com/dailysourcecode/DSC/DSC-2005-03-15.mp3
>/dev/null

response header:
HTTP/1.1 206 Partial Content
Accept-Ranges: bytes
Date: Wed, 16 Mar 2005 19:57:20 GMT
Content-Length: 12987694
Content-Type: audio/mpeg
Server: Apache/1.3.33 (Darwin)
Last-Modified: Tue, 15 Mar 2005 16:37:46 GMT
ETag: "212a498-fee016-42370f5a"
Content-Range: bytes 3715816-16703509/16703510
x-responding-server: web
Via: 1.1 netcache06 (NetCache NetApp/5.5R4)

This is correct :)

Also if I issue the comand...
curl -I -i -D header.txt -C 3715816
http://homepage.mac.com/dailysourcecode/DSC/DSC-2005-03-15.mp3
>/dev/null

reponse header:
TTP/1.1 206 Partial Content
Accept-Ranges: bytes
Date: Wed, 16 Mar 2005 19:59:27 GMT
Content-Length: 0
Content-Type: audio/mpeg
Server: Apache/1.3.33 (Darwin)
Last-Modified: Tue, 15 Mar 2005 16:37:46 GMT
ETag: "212a498-fee016-42370f5a"
Content-Range: bytes 3715816-16703509/16703510
x-responding-server: web
Via: 1.1 netcache02 (NetCache NetApp/5.5R4)

Note Content-Length: 0.

When I perform the same command on a different URL...
url -I -i -D header.txt -C 315816
http://www.apeboymonkeygirl.com/feed/uploads/DailyDownload_03_15_2005.mp3 >/dev/null

response header:
TTP/1.1 206 Partial Content
Date: Wed, 16 Mar 2005 20:02:53 GMT
Server: Apache Web Server
Last-Modified: Wed, 16 Mar 2005 08:48:23 GMT
ETag: "5f4278-2eb000-4237f2d7"
Accept-Ranges: bytes
Content-Length: 2743896
Content-Range: bytes 315816-3059711/3059712
Content-Type: audio/mp3

Note Content-Length: 2743896

So which is correct? On a head request should it report the message-body
length even though no message body is going to be sent? Maybe both are
correct? I think the latter is better so you don't have to do a Get
request to get the Content-Length and abort.

Section 14 of the RFC says
(http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.13)

14.13 Content-Length

<snip>
 The Content-Length entity-header field indicates the size of the
entity-body, in decimal number of OCTETs, sent to the recipient or, in
the case of the HEAD method, the size of the entity-body that would have
been sent had the request been a GET.
       Content-Length = "Content-Length" ":" 1*DIGIT
 An example is
       Content-Length: 3495
 Applications SHOULD use this field to indicate the transfer-length of
the message-body, unless this is prohibited by the rules in section
4.4.
Any Content-Length greater than or equal to zero is a valid value.
Section 4.4 describes how to determine the length of a message-body if a
Content-Length is not given.
<end snip>

I looked in Section 4.4 but could not find any info on the
Content-Length being equal to 0 or how to calculate the message body
length if a Content-Length not given. Could someone double check this?

So it appears Content-Length on a HEAD request should report back the
expected message-body. Does this appear to be correct?

On Wed, 2005-03-16 at 14:23 +0000, Jamie Lokier wrote:
> I have just done exactly the same request, and I get a proper response
> with a proper Content-Length. Also using curl on Gentoo:
>
> $ curl --version
> curl 7.12.0 (i686-pc-linux-gnu) libcurl/7.12.0 OpenSSL/0.9.7e zlib/1.2.2
> Protocols: ftp gopher telnet dict http file https ftps
> Features: Largefile NTLM SSL libz
> $ curl -C 3715816 http://homepage.mac.com/dailysourcecode/DSC/DSC-2005-03-15.mp3 >/dev/null
> ** Resuming transfer from byte position 3715816
> ... download proceeds to fetch 608k ...
> ... server appears to stop transferring data after 400-600k ...
> curl: (18) transfer closed with 12365102 bytes remaining to read
>
> Request headers:
> GET /dailysourcecode/DSC/DSC-2005-03-15.mp3 HTTP/1.1
> Range: bytes=3715816-
> User-Agent: curl/7.12.0 (i686-pc-linux-gnu) libcurl/7.12.0 OpenSSL/0.9.7e zlib/1.2.2
> Host: homepage.mac.com
> Pragma: no-cache
> Accept: */*
>
> Response headers:
> HTTP/1.1 206 Partial Content
> Accept-Ranges: bytes
> Date: Wed, 16 Mar 2005 14:17:58 GMT
> Content-Length: 12987694
> Content-Type: audio/mpeg
> Server: Apache/1.3.33 (Darwin)
> Last-Modified: Tue, 15 Mar 2005 16:37:46 GMT
> ETag: "212a498-fee016-42370f5a"
> Content-Range: bytes 3715816-16703509/16703510
> x-responding-server: web
> Via: 1.1 netcache02 (NetCache NetApp/5.5R4)
>
> Headers looks fine. The download does stop after tranferring 400-600k
> though - it appears as though the server simply stops sending data
> after a while.
>
> Compare with:
>
> > bash-2.05b$ curl --version
> > curl 7.12.0 (i686-pc-linux-gnu) libcurl/7.12.0 OpenSSL/0.9.7e ipv6
> > zlib/1.2.2
> > Protocols: ftp gopher telnet dict http file https ftps
> > Features: IPv6 Largefile NTLM SSL libz
> >
> > I've also tried it on a Mandrake 8.2 box...
> > daniel_at_gateway daniel]$ curl --version
> > curl 7.9.4 (i586-mandrake-linux-gnu) libcurl 7.9.4 (OpenSSL 0.9.6i)
> >
> > The headers..
> > HTTP/1.1 206 Partial Content
> > Accept-Ranges: bytes
> > Date: Wed, 16 Mar 2005 12:07:06 GMT
> > Content-Length: 0
> > Content-Type: audio/mpeg
> > Server: Apache/1.3.33 (Darwin)
> > Last-Modified: Tue, 15 Mar 2005 16:37:46 GMT
> > ETag: "212a498-fee016-42370f5a"
> > Content-Range: bytes 3715816-16703509/16703510
> > x-responding-server: web
> > Via: 1.1 netcache02 (NetCache NetApp/5.5R4)
>
> -- Jamie
Received on 2005-03-16