Re: Resume fails from mac.com

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

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