W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2005

Re: Resume fails from mac.com

From: Jamie Lokier <jamie@shareable.org>
Date: Wed, 16 Mar 2005 21:29:07 +0000
To: Daniel Czarnecki <daniel@zoltak.com>
Cc: libcurl development <curl-library@cool.haxx.se>, ietf-http-wg@w3.org
Message-ID: <20050316212907.GA5965@mail.shareable.org>

Daniel Czarnecki wrote:
> [response to HEAD request]
> Content-Length: 0
> Server: Apache/1.3.33 (Darwin)
> Content-Range: bytes 3715816-16703509/16703510
> Via: 1.1 netcache02 (NetCache NetApp/5.5R4)
> Note Content-Length: 0.
> [response to HEAD request]
> Server: Apache Web Server
> Content-Length: 2743896
> Content-Range: bytes 315816-3059711/3059712
> 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?

It "should".  It's not an absolute requirement that HEAD report the
same metainformation as GET, only a SHOULD (section 9.4, RFC2616), and
in this example it obviously does not.

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

Indeed, that's why it's specified like that.

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

4.4 is a simple sequence of rules.  If rules 1 & 2 don't apply, then
rule 3 applies which uses Content-Length (and a value of zero does
mean an empty body, there is no special exception for zero).

In the case of HEAD, rule 1 applies, which means this reponse _is_ a
well formed HTTP message, and Content-Length is not used to determine
the message length.  It could have any value, and it would be a valid
HTTP response according to the rules of section 4.4.

10.2.7 "206 Partial Content" says this:

      - Either a Content-Range header field (section 14.16) indicating
        the range included with this response, or a multipart/byteranges
        Content-Type including Content-Range fields for each part. If a
        Content-Length header field is present in the response, its
        value MUST match the actual number of OCTETs transmitted in the

Reading that literally, "MUST match the actual number of OCTETs
transmitted in the message-body", indicates that actually
"Content-Length: 0" is the only correct value in a HEAD response with
a Content-Range header.

Obviously that is not the intention of RFC2616 - the only sensible
intention is that Content-Length reflects the length that _would_ be
transmitted - but that's what it says in the RFC.

So it looks to me like a bug in RFC2616, and homepage.mac.com can be
forgiven for returning "Content-Length: 0": it's following the RFC
literally. :)

[Cc'd to ietf-http-wg@w3.org because it looks like an omission in the RFC].

-- Jamie
Received on Wednesday, 16 March 2005 21:29:11 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 1 October 2015 05:36:17 UTC