- From: Jeffrey Mogul <mogul@pa.dec.com>
- Date: Fri, 08 Aug 97 16:58:54 MDT
- To: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
Jim Whitehead points out:
The definitions of unconditional and conditional in RFC 2068 do not
remove all ambiguity -- for example, the Range header is listed as
a "MAY" capability in RFC 2068, but "origin servers and
intermediate caches SHOULD support bytes ranges." So, is the Range
header an unconditional capability?
I believe what you are referring to is (from RFC2068; unchanged in
draft-ietf-http-v11-spec-08.txt):
14.36.2 Range Retrieval Requests
HTTP retrieval requests using conditional or unconditional
GET methods may request one or more sub-ranges of the
entity, instead of the entire entity, using the Range
request header, which applies to the entity returned as the
result of the request:
Range = "Range" ":" ranges-specifier
A server MAY ignore the Range header. However, HTTP/1.1
origin servers and intermediate caches SHOULD support byte
ranges when possible, since Range supports efficient
recovery from partially failed transfers, and supports
efficient partial retrieval of large entities.
This does look like an inconsistency. "SHOULD support ... wherever
possible" is almost a tautology, anyway. I think the SHOULD here
should be "ought to", since Range support was clearly intended
to be optional.
What that means for the OPTIONS stuff is complicated by the
fact that we already invented "Accept-Ranges" as a way for the
server to indicate that is willing to accept Range headers.
Anyway, the Range header was carefully defined so that it would
(more or less) work whether it was ignored or not.
-Jeff
P.S.: We're planning, sometime "soon", to organize a "compliance-word
audit" of the HTTP/1.1 spec, to catch just this sort of thing, since we
are aware that there are many other places where the words
MUST/SHOULD/MAY are misused; some of these are simply the result of a
global replacement by a text editor one day.
Received on Friday, 8 August 1997 17:06:16 UTC