W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > September to December 1997

Re: Question on byte ranges

From: Jeffrey Mogul <mogul@pa.dec.com>
Date: Wed, 05 Nov 97 11:05:11 PST
Message-Id: <9711051905.AA11932@acetes.pa.dec.com>
To: http working group <http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com>
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/4634
Dave Kristol writes:

    My remark was, Why send a 416 in response to a well-formed header
    (whose byte-range-spec is unsatisfiable), but respond with 200 to a
    malformed header?  Why the distinction, in other words?  The
    Robustness Principle would argue against the 416 response, too,
    wouldn't it?  Surely the Content-Length or equivalent would be
    enough to clue the recipient that the byte-range-spec was

Not quite.  Content-Length is defined (section 14.14) this way:

            The Content-Length entity-header field indicates the size of
            the message-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.

For a GET request with an unsatisfiable Range request-header, the
message-body is clearly NOT going to have the same length as the
"full entity-body", and so we needed a different mechanism.

I suppose we could have used a 206 response with this kind of

	Content-Range: */200

but it was feared that this would break already-deployed implementations
that "knew" how to parse a 206 response.  Maybe this fear was groundless.


P.S.: In case anyone wishes to point out that the term "full
entity-body" in 14.17 is confusing: I agree.  18 months ago, the HTTP
editors group had a long argument over how to define the meaning
of the word "entity"; I was on the losing side.  We ended up with
no term defined to mean "the content that would be returned right
now with a status-200 response for the request".  Don't complain
to me.
Received on Wednesday, 5 November 1997 11:24:37 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:40:21 UTC