Re: 206 as a result of weak If-Range

    I've posted the question below last year but got no opinions.
    Repeated client inquiries prompted me to look at this again.
    
    In short, parts of RFC 2616 say that a server MUST use strong tag
    comparison when generating 206 responses to If-Range (i.e., weak
    If-Range MOST NOT match), while another part places requirements on
    206 responses to weak If-Range (implying that it is OK to respond with
    206 to a weak If-Range). See original post below for quotes/details.
    
    Does anybody care to comment?
    
    Or am I missing some way to generate a 206 response to a weak If-Range
    without violating any MUSTs?
    
I guess I ought to respond because I wrote most or all of these
parts of the spec.  (Sorry for dropping the ball back in October.)

You're probably right that there is a contradiction here, and that
part you quoted from RFC 2616, section 10.2.7 (206 Partial Content):

    If the response is the result of an
    If-Range request that used a weak validator, the response MUST NOT
    include other entity-headers;

is probably a bug.  That is, the entire sentence (including the
rationale after the semicolon) probably ought to be deleted.

My guess is that this contradiction arose during a revision that
made 13.3.3 stricter, and I failed to make 10.2.7 stricter as well.

This is all a bit mushy because 13.3.3 allows a sort of ambiguous
situation if the validator in question is a Last-Modified timestamp
rather than an entity tag.  Since there is no way to tag a
Last-Modified value as "weak" (or "strong", for that matter), 13.3.3
has some rather fragile rules for allowing either the client or
the server to infer strongness.  So if the heuristic here breaks
("60 seconds is too short") then it might be possible for a client
to believe that it can generate an If-Range request with a
Last-Modified value that the *client* thinks is strong, but the
*server* thinks is weak.

But in this case, it's clearly a bad idea for the server to
respond with 206, and so this language in 13.3.3:

   A cache or origin server receiving a conditional request, other than
   a full-body GET request, MUST use the strong comparison function to
   evaluate the condition.

ought to be kept in the spec, rather than that contradictory sentence
from 10.2.7.

    Would it be fair to say that the latter part documents requirements
    for violators? That is, if and only if a server decides (due to
    local configuration or whatever) to violate a MUST it becomes
    subject to another MUST?

I don't think we ever really wanted to document "requirements
for violators," since the whole point of a specification is to
give us a way to stamp out violators.  (Although during our debate
about whether badly-misguided cache operators should be allowed to
violate a server's clearly stated restrictions on caching, we
ended up resolving the debate by documenting "requirements
for violators."  But fortunately we didn't make a habit of this.)

-Jeff

Received on Tuesday, 15 April 2003 19:51:21 UTC