W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > May to August 1996

Section 13

From: Ben Laurie <ben@algroup.co.uk>
Date: Mon, 03 Jun 1996 20:27:12 +0100
Message-Id: <31B33C8F.2B8E@algroup.co.uk>
To: HTTP Working Group <http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com>
Section 13

If the cache can communicate with the origin-server, then a correct 
cache MUST respond to a request with a response that meets one of the 
following conditions:
1.	Its end-to-end headers (see section 13.4.1) and entity-body 
value are equivalent to what the server would have returned for that 
request if the resource had not been modified since the response was 
cached, by revalidating the response with the origin server, if is not 
fresh.

Shouldnt that be "checked by revalidating" and "if it is not fresh"?

2.	It is "fresh enough" (see section 13.2). In the default case, 
this means it meets the least restrictive freshness requirement of the 
client, server, and cache (see section 14.9); if the origin-server so 
specifies, it is the freshness requirement of the origin-server alone.

This would appear to operate against the ability of the client to demand 
a fresh copy (should it be the most restrictive, instead of the least 
restrictive?)


3.  It includes a warning if the freshness demand of the client or the 
origin-server is violated (see section 13.1.5 and 14.45).

If only one of the conditions must be met, when would this clause be 
invoked? Or is this a license to ignore all freshness requirements so 
long as a warning is given?

Cheers,

Ben.

-- 
Ben Laurie                   Phone: +44 (181) 994 6435
Freelance Consultant and     Fax:   +44 (181) 994 6472
Technical Director           Email: ben@algroup.co.uk
A.L. Digital Ltd.            URL: http://www.algroup.co.uk
London, England.
Received on Monday, 3 June 1996 12:22:06 EDT

This archive was generated by hypermail pre-2.1.9 : Wednesday, 24 September 2003 06:32:02 EDT