W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2002

206 as a result of weak If-Range

From: Alex Rousskov <rousskov@measurement-factory.com>
Date: Wed, 30 Oct 2002 11:47:31 -0700 (MST)
To: ietf-http-wg@w3.org
Message-ID: <Pine.BSF.4.44.0210301126320.29121-100000@measurement-factory.com>

Hi there,

RFC 2616, section 10.2.7 (206 Partial Content) says:

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

The above implies that it may be OK to respond with partial content to
an If-Range request that uses a weak validator. On the other hand,
section 13.3.3 (Weak and Strong Validators) says,

   only a strong validator is usable for a sub-range
   retrieval, since otherwise the client might end up with an internally
   inconsistent entity.

and (less importantly)

   Clients MUST NOT use weak validators
   in [subrange] forms of request.

and (more importantly)

   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.

which seems to imply that a 206 Partial Content response cannot be a
result of an If-Range request that used a weak validator. In other
words, section 10.2.7 seems to be documenting specifics of the
behavior that is prohibited in section 13.3.3 because, according to
13.3.3, weak If-Range should never match and the server MUST respond
with 200 (OK) and not 206 (Partial Content).

My question is: [How] is it possible for a compliant implementation to
generate a 206 Partial Content response as a result of an If-Range
request that used a weak validator?

Thank you,


                            | HTTP performance - Web Polygraph benchmark
www.measurement-factory.com | HTTP compliance+ - Co-Advisor test suite
                            | all of the above - PolyBox appliance
Received on Wednesday, 30 October 2002 13:47:36 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:10:36 UTC