Opened 9 years ago

Closed 7 years ago

#212 closed design (fixed)

Refining age for 1.1 proxy chains

Reported by: mnot@… Owned by: mnot@…
Priority: later Milestone: 18
Component: p6-cache Severity: Active WG Document
Keywords: Cc:


A lot of the text in 2616's caching section -- especially around age calculation -- was explanatory, not spec text. Most of it has been removed in p6-07, but some still remains, and my take is that this is one example of this.

As you've noticed, the algorithm is very conservative; i.e., it will always err on the side of considering something older than it actually is. This is annoying when the freshness lifetime is short (or the skew very large), as you point out making things that could have been cacheable uncachable.

Since transit time is already accounted for here (related issue: <

), it seems like the wild card that you have to deal with is HTTP/

1.0 caches not emitting Age headers.

Just having a 1.1 origin isn't necessarily good enough, because there could (in theory) be a 1.0 cache interposed somewhere along the way; remember, they aren't required to emit Age nor Via, and while the next hop towards the UA *should* record it in the Via header (presuming it's 1.1), as we know not everyone sends them.

I'm wondering if it's good enough to specify that if:

  • your next hop is a proxy AND it sends a Via header that's all

1.1, OR

  • your next hop is the origin, and if the Via header is present

it's all 1.1 you can calculate age using the age header without trying to account for hidden 1.0 caches in the chain (using Date).

This does have the potential to mess up in a few circumstances, but AFAIK 1.0 caches will produce Age anyway; e.g. Squid. Most of the other caches deployed are going to be either accelerators/CDNs (which already do unholy things with Date and Age; see Edith Cohen's paper from a while back), or interception caches, which are responsible for any problems they cause anyway.

Thoughts? An alternative would be to reduce the Date portion of the calculation to a SHOULD-level requirement.

See also$fdc07660$f9416320$@org and previous in thread.


response_delay = response_time - request_time; corrected_age_value = age_value + response_delay; if (reponse_version_1_1 && !response_via_1_0) {

corrected_initial_age = corrected_age_value;

} else {

apparent_age = max(0, response_time - date_value); corrected_initial_age = max(apparent_age, corrected_age_value);

} resident_time = now - response_time; current_age = corrected_initial_age + resident_time;

Change History (7)

comment:1 Changed 9 years ago by mnot@…

  • Priority changed from normal to low

comment:2 Changed 8 years ago by mnot@…

Proposal - replace:

These are combined as

corrected_initial_age = max(apparent_age, corrected_age_value);


These SHOULD be combined as

corrected_initial_age = max(apparent_age, corrected_age_value);

unless the cache is confident in the value of the Age header (e.g., because there are no HTTP/1.0 hops in the Via header), in which case the corrected_age_value MAY be used as the corrected_initial_age.

comment:3 Changed 8 years ago by mnot@…

  • Owner set to mnot@…

comment:4 Changed 7 years ago by mnot@…

  • Resolution set to incorporated
  • Status changed from new to closed

comment:5 Changed 7 years ago by mnot@…

  • Milestone changed from unassigned to 18

comment:6 Changed 7 years ago by mnot@…

  • Resolution incorporated deleted
  • Status changed from closed to reopened

comment:7 Changed 7 years ago by mnot@…

  • Resolution set to fixed
  • Status changed from reopened to closed
Note: See TracTickets for help on using tickets.