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

Re: If-Range with other conditionals

From: Alex Rousskov <rousskov@measurement-factory.com>
Date: Wed, 25 Sep 2002 09:08:27 -0600 (MDT)
To: Jeffrey Mogul <Jeff.Mogul@hp.com>
cc: ietf-http-wg@w3.org
Message-ID: <Pine.BSF.4.44.0209250847420.43968-100000@measurement-factory.com>

On Tue, 24 Sep 2002, Jeffrey Mogul wrote:

>     Here is what we currently do to test the proxy-related MUST in
>     question: generate all possible combinations of If-* headers that do
>     not violate other MUSTs, make on of the If- header mismatch LMT/tag of
>     the cached entity, and then make sure that the proxy under test does
>     not return any cached information (including headers). The proxy can
>     return any status codes. Do you think that's the best strategy of
>     verifying the MUST in question?
>
> In general, a proxy "cache" should be able to meet all of the
> caching-related parts of RFC2616 by shrinking its cache size to
> zero, so a cache that passes your test could be compliant, but
> I'm not sure that it's *necessarily* compliant.  That is, I'm
> not sure that your approach actually tests all of the MUSTs
> in the spec.  There might be some interactions with Cache-Control
> headers that you need to test, too.

Yes, of course. The above approach is used for the "combination of
If-* headers" test cases only. There are more than 500 test cases
covering everything else, including Cache-Control handling. For the
majority of [caching] MUSTs it is possible to test in a more
specific/direct way when the cache has to act on stored content.  The
above is simply a workaround because we seem to be hitting an
"undefined behavior" ground when many If-* headers are combined in a
request.

> I'm also assuming that you limit your testing to GET/HEAD methods,
> since nobody has really worked out how HTTP caches deal with PUTs or
> POSTs in all possible cases (except by simply forwarding these).

Hmm... RFC 2616 has a few MUSTs related to non-GETs and caches/proxies
that we do test. For example, some proxies retry POST requests, many
proxies cannot handle chunked POSTs, and most caches do not invalidate
cached entities mentioned in *Location request headers.  Co-Advisor
can detect those MUST violations quite well.

We do not do formal protocol verification though (as opposed to Adam
Bradley's research). Our test subject is the implementation, not the
spec.

Thank you,

Alex.

-- 
                            | HTTP performance - Web Polygraph benchmark
www.measurement-factory.com | HTTP compliance+ - Co-Advisor test suite
                            | all of the above - PolyBox appliance
Received on Wednesday, 25 September 2002 11:08:33 GMT

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