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 Thursday, 23 April 1998 13:47:19 UTC