- From: Jeffrey Mogul <mogul@pa.dec.com>
- Date: Wed, 05 Nov 97 11:05:11 PST
- To: http working group <http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com>
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
unsatisfiable.
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
thing:
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.
-Jeff
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