TR: question in caching in the HTTP1.1

> ----------
> De : 	MOKHTAR Ahmed CNET/DSM/REN
> 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
> A :	MOKHTAR Ahmed CNET/DSM/REN
> 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