inconsistent use of MAY & SHOULD in 14.36.2 Range Retrieval Requests

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

	    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.


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