- From: Paul Hethmon <phethmon@utk.edu>
- Date: Mon, 25 Nov 1996 23:45:02 EST
- To: "Roy T. Fielding" <fielding@liege.ICS.UCI.EDU>, HTTP-WG <http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com>
Addressed to: "Roy T. Fielding" <fielding@liege.ICS.UCI.EDU> HTTP-WG <@hplb.hpl.hp.com:http-wg@cuckoo.hpl.hp.com> ** Reply to note from "Roy T. Fielding" <fielding@liege.ICS.UCI.EDU> Mon, 25 Nov 1996 19:52:31 -0800 > > should be 13? Basically, at each cache, the Age value will > > be increased by the response_delay of that cache (plus > > resident_time if applicable). > > Regardless of what it says in the spec, the Age value is not touched > by the cache unless resident_time > 0. In other words, a cache does > not age a response that it has never had in its possession. It is only > when resident_time > 0 (the response is coming from the cache and > not from an upstream server) that the cache sets the Age value in > the message. Are we making a distinction here between "proxies" and "caches" then? It seems the wording in 14.6 still requires caches to send the Age header, even if acting more as a proxy. Henrik's code that he posted earlier seems to follow this too. As an implementer, I take the wording to mean calculate the Age value and send it everytime even if I've just received the response and it's not really in the cache yet. Putting that aside though, my real question went back to the discussion in July between you and Jeff Mogul over the algorithm. I guess your point here still reflects that. It does seem the algorithm (if all caches send Age) can easily inflate the value. More so if there are multiple caches in a chain and the resource is kept resident for any length of time in each. Paul Paul Hethmon phethmon@utk.edu phethmon@hethmon.com ---------------------------------------------------------- Inet.Mail for OS/2 -- Internet Mail Server ---------------------------------------------------------- www.hethmon.com -- ftp.hethmon.com ----------------------------------------------------------
Received on Monday, 25 November 1996 20:48:16 UTC