W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2003

Re: 206 as a result of weak If-Range

From: Alex Rousskov <rousskov@measurement-factory.com>
Date: Tue, 15 Apr 2003 22:39:28 -0600 (MDT)
To: ietf-http-wg@w3.org
cc: Scott Lawrence <scott-http@sbrk.org>
Message-ID: <Pine.BSF.4.53.0304152220430.81951@measurement-factory.com>

Jeff,

	Thanks for the explanation! The situation seems to be clear
now. Based on your comments, it looks like the questionable part from
section 10.2.7 should be added to the HTTP errata document. The
comment could say something like "ignore this MUST and its motivation
because it contradicts the language of section 13.3.3 and the intent
behind 206 (Partial Content) safety mechanisms".

	If there are no objections, I would like to ask Scott Lawrence
to update the errata page. While I do not belive this is a big issue,
it is a bug that still raises questions among developers that are
concerned with RFC 2616 compliance.

Thank you,

Alex.

P.S. Your comments regarding different client and server views on the
strength of a date-based validator are very interesting. I would have
to digest it some more, but there may be something we can test for
there.


On Tue, 15 Apr 2003, Jeffrey Mogul wrote:

>     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 Wednesday, 16 April 2003 00:39:33 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:49:23 GMT