- From: Alex Rousskov <rousskov@measurement-factory.com>
- Date: Tue, 6 Jul 2004 10:40:57 -0600 (MDT)
- To: Greg Robson-Garth <gregrg@optusnet.com.au>
- Cc: ietf-http-wg@w3.org
On Tue, 6 Jul 2004, Greg Robson-Garth wrote: > 1. Date > > In a cache server, assuming the message is now resident in the cache > and has been requested by a HTTP client. Should the cache server > send with message with: > > a) the Date header as it received it from the origin server Yes, if there was one. Otherwise, "A received message that does not have a Date header field MUST be assigned one by the recipient if the message will be cached by that recipient" > 2. Age > > Does the Age header represent the seconds relative to the date/time in the > date header. Not always. "The Age field value is the cache's estimate of the amount of time since the response was generated or revalidated by the origin server. In essence, the Age value is the sum of the time that the response has been resident in each of the caches along the path from the origin server, plus the amount of time it has been in transit along network paths." > So if the Age is say Age: 60 and the time is 03:00:00, then its > birth time (for a want of a better word) is 02:59:00. If this is the > case, then surely the correct calculation of corrected_received_age > in 13.2.3 should be > > now - date_value + age_value The (now - date_value) part is usually the age we want. "Age_value" from the Age: header is usually a little smaller than (now - date_value) age because it does not account for network delays. The age calculation algorithm in RFC 2616 is indeed buggy, but in a different, more subtle, way: http://lists.w3.org/Archives/Public/ietf-http-wg/2002JulSep/0048.html IIRC, nobody commented on that age calculation bug and its proposed fix. It is not mentioned in the RFC 2616 errata. I suspect it will remain with us forever. Alex.
Received on Tuesday, 6 July 2004 12:41:01 UTC