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

question in caching in the HTTP1.1

From: MOKHTAR Ahmed CNET/DSM/REN <ahmed.mokhtar@cnet.francetelecom.fr>
Date: Thu, 23 Apr 1998 10:11:47 +0200
Message-Id: <425A62747E7CD111B4570060974B1C631E72B1@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/70
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. 

a is the user agent
b,c are x caching servers (clients)
d is the origin server

if a send a request 1 to server d and then we calculate the
which is equal to the period between sending the response from the server
till this moment, it will be enough to indicate the real age of the
but if we add now - request time it will be overhead which is not the real
value of the age of entry
NUMERIC exampe
if a send the request at time 0 and d received the request at time 6 and
send the respond at time 8 and a recieves the response at time 10, the date
value will be 8 and now will be 10 so the corrected recieved age will be 2,
now let us say that this response was created at the server at time 7 and
with life_time (max age) equals to 11 i.e if the age is less than 10 for our
case we should not try to reload and the response for any farther request
before the time 18 (7+11) should be fresh, so no more request to the origin
now let us go to step two and calculate the corrected_inital_age (which I
don't agree with) the value will be the correct age + (now - reaquest time)
now = 11 < 18 should not reload
but due to the calulations
age = 2 ( initial date) + (11 - 0) = 13 > max age then stale ##

so I propose to remove this overhead from the age calculation

Ahmed Mokhtar
Received on Thursday, 23 April 1998 01:31:06 UTC

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