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

TR: question in caching in the HTTP1.1

From: MOKHTAR Ahmed CNET/DSM/REN <ahmed.mokhtar@cnet.francetelecom.fr>
Date: Thu, 30 Apr 1998 08:23:50 +0200
Message-Id: <425A62747E7CD111B4570060974B1C631E72BA@r-mhs.ccett.fr>
To: "'http-wg@cuckoo.hpl.hp.com'" <http-wg@cuckoo.hpl.hp.com>
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/88

> ----------
> Date :	jeudi 30 avril 1998 08:22
> A :	'Jeffrey Mogul'
> Objet :	RE: question in caching in the HTTP1.1 
> I didn't understand clearly what is the relation between transparency and
> the error on the age calculation. 
> about the synch. between caches, may be the SCSP solves the problem at
> some time in the future.
> and talking about the transparency, what do you think about CARP
> effeciency in that matter. I mean don't you think that CARP violate the
> transparency.
> Ahmed
> ----------
> De : 	Jeffrey Mogul[SMTP:mogul@pa.dec.com]
> Date :	jeudi 23 avril 1998 21:36
> Cc :	'http-wg@cuckoo.hpl.hp.com'
> Objet :	Re: question in caching in the HTTP1.1 
> MOKHTAR Ahmed CNET/DSM/REN <ahmed.mokhtar@cnet.francetelecom.fr> writes:
>     my question concern caching in http 1.1 about the expiration model
>     rfc 2068 page 53 you get the corrected_initial_age by adding
>     corrected_received_age to a new term which is (now-request_time) I
>     think this will give some misleading results because now-request
>     time is equal to the transaction period.
> First of all, you should refer to draft-ietf-http-v11-spec-rev-03,
> not RFC2068, for any discussion of the text of the HTTP/1.1
> specification.
> In any case, the goal of this Age calculation is to support the
> "transparency" requirements for caching, described at the beginning
> of Section 13 of the specification.  In particular, we have 
>   A basic principle is that it must be possible for the clients to
>   detect any potential relaxation of semantic transparency.
> The goal of the age calculation is to discover whether a response
> is fresh.  In order to meet this principle, we need to err on the
> side of caution; that is, we would rather treat a fresh response
> as stale (and needed revalidation) than treating a stale response
> as fresh (thereby presenting a user with out-of-date information).
> Given that there is no way to calculate the precise age of a
> response in a distributed system with (possibly) unsynchronized
> clocks, the Age calculation described in the HTTP/1.1 specification
> is designed to overestimate the Age, rather than to underestimate
> it.  This preserves the property that clients can detect potentially
> stale responses; it may cause a few unnecessary reloads, but generally
> if the remaining freshness lifetime of a response is so close to
> the error in the Age calculation that it causes an unnecessary
> reload, then probably we are dealing with a response whose original
> freshness lifetime is short ... this means that someone really wants
> to avoid a stale response in this case.
> -Jeff
Received on Wednesday, 29 April 1998 23:37:30 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 2 February 2023 18:43:05 UTC