Subject: Meaning of header fields Date: and Age:

From: "Greg Robson-Garth" <[email-masked]>
Date: Tue, 6 Jul 2004 06:53:30 -0400 (EDT)

What do these fields mean ?

According to "the spec", RFC2616 the Date header is the date/time the
message was generated at the origin server.

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

b)       generate a new Date header being the date/time the message is sent
from the cache and calculate the age as the residence time

2. Age

Does the Age header represent the seconds relative to the date/time in the
date header. 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

Can anyone comment ?

--Greg

Author, FreeProxy

---

From: Alex Rousskov <[email-masked]>
Date: Tue, 6 Jul 2004 10:40:57 -0600 (MDT)

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:
>

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"

> 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
>

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.

---

From: Koen Holtman <[email-masked]>
Date: Tue, 6 Jul 2004 17:24:57 -0400 (EDT)

Hi Alex,

> fix. It is not mentioned in the RFC 2616 errata. I suspect it will

I recall that this bug (and ways to fix it) did get discussed back in the
late 1990s when the spec was being written.  Opinions ranged from `it is a
bug' to `this is a safe way for the calculation to err on the side of
caution'.  I recall that the original author of the calculation (Jeff
Mogul) did intend it this way.  Consensus back then was that the
bug/feature should be kept in.

> Alex.

Koen.

---

From: Alex Rousskov <[email-masked]>
Date: Tue, 6 Jul 2004 16:02:50 -0600 (MDT)

On Tue, 6 Jul 2004, Koen Holtman wrote:

> > The age calculation algorithm in RFC 2616 is indeed buggy, but in
> > a different, more subtle, way:
> > 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.
>
> I recall that this bug (and ways to fix it) did get discussed back
> in the late 1990s when the spec was being written.  Opinions ranged
> from `it is a bug' to `this is a safe way for the calculation to err
> on the side of caution'.  I recall that the original author of the
> calculation (Jeff Mogul) did intend it this way.  Consensus back
> then was that the bug/feature should be kept in.

Thanks for the info! I may have found that e-mail thread:
http://www.hpl.hp.com/personal/ange/archives/http-wg-archive/0378.html

Jeff Mogul said, "The fact that the response_delay is counted twice in
the final result is an attempt to correct for clock skew, since if you
can't guarantee that the client and server clocks are synchronized
(and we can't!), then the apparent_age could be wrong by a significant
amount."

The formulas I proposed do not use apparent_age or response_delay, so
I cannot apply the above logic directly. Unfortunately, I do not know
what Jeff was using to estimate "clock skew" effect on a formula, so I
am not sure whether the simpler formulas I came up with suffer from
clock skew more than the current complex ones.

As of now, I am only sure that the complexity (and unexpected
results?) of current formulas lead to implementation bugs. I am not
sure whether simpler, natural formulas do not suffer from higher clock
skew sensitivity.

Thanks,

Alex.