TR: question in caching in the HTTP1.1
MOKHTAR Ahmed CNET/DSM/REN (ahmed.mokhtar@cnet.francetelecom.fr)
Thu, 30 Apr 1998 08:23:50 +0200
> ----------
> De : MOKHTAR Ahmed CNET/DSM/REN
> Date=A0: jeudi 30 avril 1998 08:22
> A : 'Jeffrey Mogul'
> Objet : RE: question in caching in the HTTP1.1=20
>=20
> I didn't understand clearly what is the relation between transparency =
and
> the error on the age calculation.=20
> 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.
>=20
> Ahmed
>=20
> ----------
> De : Jeffrey Mogul[SMTP:mogul@pa.dec.com]
> Date=A0: 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=20
>=20
> 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.
>=20
> 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.
>=20
> 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=20
>=20
> A basic principle is that it must be possible for the clients to
> detect any potential relaxation of semantic transparency.
>=20
> 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).
>=20
> 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.
>=20
> -Jeff
>=20
>=20