- From: MOKHTAR Ahmed CNET/DSM/REN <ahmed.mokhtar@cnet.francetelecom.fr>
- Date: Thu, 23 Apr 1998 10:11:47 +0200
- To: "'http-wg@cuckoo.hpl.hp.com'" <http-wg@cuckoo.hpl.hp.com>
Hi 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. Eample *a---------------------------*b_______*c------------------------*d 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 corrected_recieved_age. 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 response. 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 server. 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