The Gold Standard of Websites | Carrying Response Age Across More Than One Cache

Imagine a library sending a copy of a dated notice through two desks. The second desk receives the paper later, but the notice does not become newly issued because someone puts it in a different tray. The issue date and the journey remain relevant.

That analogy helps separate arrival from age, but it has limits. HTTP carries defined metadata and uses specified calculations; it does not infer age from a person’s reading of the prose. A response’s Date value is also not the publication date of every fact in its body. A freshly generated response could contain an outdated timetable if the underlying editorial information is wrong.

For our exercise, follow one stored response representing one selected resource variant. Do not combine timing from one response with the body or headers of another. Before subtracting any numbers, give the response a label, such as Notice A, and keep that label throughout the ledger.

The question we will answer is operational and bounded: at a stated decision time, does the calculated age fall below the supplied freshness lifetime? We will not infer when the author last checked the notice, whether every cache may store it, or whether a visitor’s whole task succeeds. Those require separate evidence.

Contents · Next chapter

Use five inputs at the receiving cache. Date is the response’s supplied Date value. Age is the supplied age value, treated as zero when absent for this calculation. Request time is when this cache initiated the request that produced the response. Response time is when it received that response. Now is the later moment at which we assess the stored response.

Request time, response time and now belong to the receiving cache’s timing record. Do not substitute the time at which a teacher starts explaining the example or the instant an upstream cache originally stored its copy. The labels identify particular events.

We use an arbitrary zero on a common numerical timeline to keep the arithmetic visible. A real HTTP Date is a date-time field, not a bare number such as forty. Turning a valid date-time into seconds for arithmetic requires the actual protocol’s parsing and clock rules. Our numbers are already supplied in compatible units.

Write the inputs before calculating derived ages. This makes a useful diagnostic possible: another reader can distinguish a bad subtraction from a correctly performed subtraction using the wrong event. Both can produce an incorrect result, but they require different repairs. A clean column of arithmetic cannot rescue an event label that changed meaning halfway through the explanation.

Contents · Previous chapter · Next chapter

RFC 9111, HTTP Caching, particularly section 4.2.3, defines the age inputs and calculation. For this lesson we choose its conservative route: compare an apparent-age estimate with an Age-based estimate corrected for response delay, then add residence time. The specification also permits using the corrected Age-based estimate directly under its stated conditions.

Our exercise therefore does not claim that every conforming implementation must always take the maximum we use. We choose one permitted route and apply it consistently. This matters when two implementations produce different estimates from the same simplified inputs: the difference needs interpretation before anyone declares a defect.

For readable working, define apparent age as the larger of zero and response time minus Date. Define response delay as response time minus request time. Add that delay to the supplied Age value. The larger of the apparent and corrected Age-based estimates is our chosen initial age.

Finally, residence time is now minus response time. Add it to the initial age. These are calculation roles rather than five competing meanings of freshness. Keeping the sequence explicit helps us locate whether an error arose before arrival, during the transfer, or during later storage.

Contents · Previous chapter · Next chapter

Let Cache A request Notice A at time 2 and receive it at time 4. The supplied Date corresponds to time 0, the supplied Age is zero, and the exercise gives a freshness lifetime of sixty seconds. We assume the response is otherwise eligible for the particular reuse under discussion.

Apparent age is max(0, 4 − 0) = 4 seconds. Response delay is 4 − 2 = 2 seconds. The corrected Age-based estimate is 0 + 2 = 2 seconds. Our conservative initial age is the larger value, four seconds.

At time 10, residence time is 10 − 4 = 6 seconds. Current age is therefore 4 + 6 = 10 seconds. At time 40, residence time is thirty-six seconds and current age is forty seconds. Neither calculation starts the response’s age at its arrival at time four.

Pause before introducing another cache. Ask the learner to explain why age at time ten is not six. Six is a correct residence duration. It answers how long this cache has held the response, which is only one part of the age calculation. The repair is to restore the omitted initial-age term, not to change the subtraction that correctly produced six.

Contents · Previous chapter · Next chapter

Now Cache B initiates a request at time 38. Cache A supplies its stored response at time 40, carrying the forty-second age estimate in our stipulated record. Cache B receives the response at time 43. Date remains time zero for this unvalidated response in the example.

At B, apparent age is forty-three seconds. Its response delay is 43 − 38 = 5 seconds. The corrected Age-based estimate is 40 + 5 = 45 seconds. Taking the larger estimate gives an initial age of forty-five seconds on arrival.

That result may look surprising because the common timeline says forty-three seconds have passed since time zero. The selected method is an estimate that includes the receiving request’s delay. It need not reconstruct an exact physical stopwatch age. Here it is conservative by two seconds. Do not quietly remove those two seconds merely to make the ledger look more intuitive.

The new arrival did not erase forty seconds of prior age. Nor did B add a completely new sixty-second lifetime. The decisive change is that B starts its own residence calculation with an inherited, corrected age estimate. The body may have arrived moments ago while most of its freshness lifetime has already been consumed.

Contents · Previous chapter · Next chapter

At time 60, Cache B has held the response for 60 − 43 = 17 seconds. Add that residence time to the forty-five-second initial age: the current estimate is sixty-two seconds. Keep each derived quantity beside the inputs that produced it.

Read the table vertically rather than jumping from incoming Age to a final judgment. A common mistake adds seventeen to forty and obtains fifty-seven. That preserves upstream age and local storage but omits the five-second correction selected by our method.

Another mistake subtracts Date from now and uses sixty without following the chosen algorithm. That may look plausible on this clean common-clock timeline, but it does not reproduce the forty-five-second initial estimate we explicitly selected. A worked result must remain consistent with its declared method, including the method’s conservative character.

Contents · Previous chapter · Next chapter

For the simple freshness comparison, the supplied lifetime must be greater than current age. At B’s arrival, sixty is greater than forty-five, leaving fifteen seconds before the equality boundary. At time 57, residence is fourteen and age is fifty-nine: the age test still passes.

At time 58, residence is fifteen and age is sixty. The strict freshness test no longer passes. At time 60, age is sixty-two, so it also fails. Saying the response was received seventeen seconds ago does not change either comparison.

This is a classification under the exercise’s assumptions. We deliberately do not turn it into an instruction that B should return a particular network response. Successful validation, explicitly permitted stale service, request conditions and other rules belong to the complete reuse decision. An expired age test does not imply that stored bytes have disappeared.

The exact boundary is educationally useful. If a learner writes less-than-or-equal instead of less-than, the mistake changes the classification precisely at equality. Test the boundary rather than only examples far away from it. A student who can explain fifty-nine, sixty and sixty-two is showing control of the rule, not simply recognition that seventeen is smaller than sixty.

Contents · Previous chapter · Next chapter

The first shortcut is residence-only age: current age equals time since this cache received the response. In B’s case it produces seventeen seconds at time sixty. It is easy to compute and wrong for our ledger because it discards the response’s initial age.

The second shortcut is to restart the lifetime after every hop. That would let B treat the copy as fresh until time 103, sixty seconds after arrival. Compare that with the chosen-method equality boundary at fifty-eight. The discrepancy is forty-five seconds, exactly the initial age that was ignored.

The third shortcut is to add every age-like number in sight. At arrival, adding apparent age forty-three to corrected Age forty-five gives eighty-eight. Those two values are alternative estimates combined by a maximum in our chosen route, not successive durations. Adding both would count overlapping history twice.

Ask what each term measures before deciding whether to add or compare it. This habit transfers beyond HTTP: two estimates of the same quantity should not automatically be added, while successive non-overlapping durations often should. The operation follows the meaning. Naming a column “time” is not enough to establish whether its values are intervals, timestamps, estimates or allowances.

Contents · Previous chapter · Next chapter

Keep B’s request at time 38, incoming Age forty and Date zero, but suppose receipt is at time 50. This is a new hypothetical timing case rather than a claim that Cache A sent the same message at the same instant under every arrangement.

Apparent age is fifty. Response delay is twelve. Corrected Age is fifty-two, so chosen initial age is fifty-two. Only eight seconds remain before equality with the sixty-second lifetime. At time fifty-eight, residence is eight and age reaches sixty again for these particular stipulated inputs.

Do not elevate that repeated boundary into a universal rule. In these two examples the incoming Age and request time were held fixed and the corrected Age-based branch dominated. Algebraically, adding response delay and later residence cancels the response-time term. A different Date value or dominant branch can change the pattern.

Now make receipt time seventy. The initial age becomes seventy-two by the same selected route, already above sixty. A newly received object can therefore arrive failing the freshness age test. No local waiting period is required to produce that result. The explanation is accumulated age plus the stipulated delay, not a mysterious failure of the receiving cache’s storage clock.

Contents · Previous chapter · Next chapter

Return to request time thirty-eight, receipt forty-three and incoming Age forty. Change the supplied Date to time fifty, later than receipt on this teaching timeline. The apparent-age subtraction is negative, so that branch is clamped to zero.

The corrected Age-based branch remains forty-five. Our chosen initial age therefore remains forty-five. A future-looking Date does not force an accumulated response-age estimate back to zero in this example. That is one reason the separate inputs should remain visible.

This classroom change does not establish why a real Date appears ahead of a local clock. Clock offset, invalid records and the actual HTTP rules require investigation. We are testing the formula’s response to a supplied value, not diagnosing a production system from one inconsistent timestamp.

Change Date instead to minus twenty. Apparent age is then sixty-three, larger than corrected Age forty-five. The chosen initial age becomes sixty-three, and the response fails the sixty-second age test on arrival. This pair of changes is a useful transfer check: the learner must evaluate both branches afresh rather than remember that incoming Age forty always produces initial age forty-five.

Contents · Previous chapter · Next chapter

Use the original B case again. At time 50, B’s residence is seven seconds and its current estimate is fifty-two. Suppose it supplies that estimate to Cache C under the exercise’s otherwise eligible reuse assumptions. C requested at time 48 and receives at time 53, with Date zero.

C’s apparent age is fifty-three. Its delay is five, and corrected Age is 52 + 5 = 57. The selected initial age is fifty-seven. At time 55, residence is two and current age is fifty-nine. At time fifty-six, current age reaches sixty and the strict age test stops passing.

The table follows one stipulated route, not a universal timing topology. Its purpose is to expose the invalid reset. Adding a layer does not create a new response generation event. It creates another receiving ledger with an incoming estimate and its own measured interval.

Contents · Previous chapter · Next chapter

So far, the exercise supplies a sixty-second lifetime directly. That choice isolates age. In a complete cache, lifetime selection itself depends on the response metadata and the type of cache. RFC 9111 section 4.2.1 is the source to consult for that selection.

For one limited illustration, suppose the response supplies max-age of sixty and s-maxage of thirty. A shared cache uses the applicable shared-cache lifetime rather than simply copying a private cache’s sixty-second allowance. At B’s original arrival age of forty-five, the thirty-second age test already fails.

Notice what changed: the lifetime, not the calculated age. The incoming age, request and response events stayed the same. Recomputing forty-five because the lifetime changed would mix two separate parts of the decision.

When teaching this distinction, cover the lifetime column and ask the learner to calculate age. Then reveal the applicable lifetime and ask for the comparison. This temporary separation is a learning aid, not a software design prescription. It helps locate whether an incorrect final label arose from an arithmetic mistake, an inappropriate lifetime or an omitted rule beyond freshness. Real systems must put the complete decision back together.

Contents · Previous chapter · Next chapter

A useful consistency test changes the labels on the time axis without changing any event intervals. Add one thousand seconds to every timestamp in B’s original case: Date becomes 1000, request 1038, receipt 1043 and assessment 1060. Incoming Age remains forty because it is a duration, not a timestamp.

Apparent age is 1043−1000=43. Delay is 1043−1038=5, and residence is 1060−1043=17. The selected initial age is still 45 and current age is still 62. Changing the numerical origin of a compatible timeline cannot change these differences.

Now consider a deliberately incorrect transformation: add one thousand to incoming Age as well. That would turn a forty-second duration into 1040 seconds without changing the underlying journey. It would grossly increase the result. The error is not arithmetic; it is treating a duration as though it were an absolute clock reading.

A second incorrect transformation shifts only the receiving cache’s timestamps while leaving the supplied Date unchanged. Apparent age becomes 1043, while delay and residence remain five and seventeen. This is no longer merely a relabelling of a common timeline. It creates a cross-clock offset in the apparent-age branch. Our exercise would choose a much larger initial age, but the sensible investigative question is whether the inputs share the required time basis.

Do not automatically subtract one thousand from a real log because the classroom example did so. An actual offset must be established from the clocks and records involved. Otherwise a proposed correction can manufacture agreement while destroying the original evidence. Keep the raw timestamps and the justified mapping separately.

This check gives a learner three categories to recognise: timestamps move when the common origin changes; elapsed durations do not; and comparisons between clocks require a compatible reference. Those categories are more durable than memorising a particular row of the table. They also help explain why changing a viewer’s displayed time zone should not create extra response lifetime: the underlying elapsed interval has not changed.

Try the same exercise with Cache D. Add two hundred to Date 80, request 100, receipt 104 and now 109. The inputs become 280,300,304 and 309. Apparent age remains 24, delay 4 and residence 5, giving the original current age 29. Leave incoming Age 18 unchanged. If the resulting worksheet reports 229, locate which duration was incorrectly shifted before changing the final freshness comparison.

Contents · Previous chapter · Next chapter

Our multi-cache examples intentionally contain no successful origin validation between the stated events. That is why receiving the response at another layer cannot be treated as evidence of a new origin check.

A validation exchange is a different event. It can change the metadata relevant to reuse while allowing an existing body to remain useful. The CDN Mathematics guide explains conditional requests, transfer savings and the surrounding cache system. Follow the actual response and update rules rather than resetting every field whenever the word validation appears in a log.

For a paper audit, mark each network exchange as a full response, a specified validation result, or an unresolved record. Do not infer successful origin validation merely from a local cache-hit label. Nor does identical body text prove that no validation occurred; a validation can confirm an unchanged representation.

This distinction also explains why our age lesson does not reproduce the separate editor save-conflict guide. Protecting accepted edits and deciding whether a stored response is fresh are connected maintenance concerns, but they use different events and answer different questions.

Contents · Previous chapter · Next chapter

Imagine that the origin generates a response at time zero containing last month’s opening hours. Every age subtraction can be correct, and the sixty-second freshness test can pass, while the visitor still receives inaccurate information. The protocol did not inspect the factual contents of the notice.

Now imagine accurate text that is still displayed in an already open page after a newer version has been published. Our stored-response freshness calculation does not by itself describe every display or history mechanism. Establish which layer produced the visitor’s observation before applying this ledger.

Keep three questions on the evidence card: which representation was selected, what the cache’s reuse decision meant, and whether the content served the visitor’s real information need. A result about one cannot silently answer the other two.

For students, ask for two conclusions from the same fictional case. The technical conclusion might state that the selected response had calculated age fifty-nine against a supplied lifetime sixty at the decision moment. The reader-facing conclusion should be more modest unless editorial checking is also supplied. No arithmetic on headers establishes that the opening hours are correct for every date, location or exception.

Contents · Previous chapter · Next chapter

Try a changed case without using the earlier table. Cache D requests at time 100 and receives at time 104. The response carries Date corresponding to eighty and incoming Age eighteen. The assessment moment is 109, with an applicable lifetime of thirty seconds. Use the same conservative route.

Apparent age is twenty-four. Delay is four and corrected Age is twenty-two, so initial age is twenty-four. Residence is five and current age is twenty-nine. The strict age test passes at 109; at time 110, age reaches thirty and it no longer passes.

Now change only incoming Age to twenty-eight. Corrected Age becomes thirty-two, which dominates apparent age twenty-four. At time 109, current age is thirty-seven. The copy is not fresh under the thirty-second age test even though D has held it for only five seconds.

Finally change the request time from one hundred to ninety-eight while retaining the original Age eighteen and receipt 104. Delay becomes six, corrected Age twenty-four, and the two branches tie. Initial age stays twenty-four. This is a useful check against the habit of assuming every input change must change the output. A maximum can absorb a change until a different branch becomes larger.

A practical comparison should also preserve the units of every exported column. A log that records milliseconds must be converted before it is combined with an Age value expressed in seconds. Changing the unit label alone changes neither the stored number nor its meaning. Retain both the original value and the explicit conversion in the worksheet.

Contents · Previous chapter · Next chapter

Suppose a screenshot shows Date and incoming Age but not request or response times. The complete calculation in this lesson is not reconstructible from that screenshot alone. Do not fill in a zero response delay because the image omitted it.

Conversely, a file’s local modification timestamp is not automatically the required response-time record. A copy operation, processing step or metadata conversion can change what that timestamp represents. The event contract comes before the subtraction.

Build an audit record that names the response identity, cache type, relevant headers, request and receipt events, assessment time, selected calculation route, applicable lifetime and any other reuse restriction being considered. Preserve original observations separately from explanatory calculations. If the upstream estimate is only known within a supplied range, carry that uncertainty through the monotone additions and maximum rather than print a falsely exact age.

For example, if incoming Age is stipulated between thirty-nine and forty-one in B’s original timeline, corrected Age lies between forty-four and forty-six. It exceeds apparent age forty-three throughout, so the selected initial-age range is forty-four to forty-six. At time sixty, the age range becomes sixty-one to sixty-three. Both endpoints fail the sixty-second age test. The range supports a stable classification under these assumptions without pretending the exact value is known.

Contents · Previous chapter · Next chapter

Consider this student response: “B received the file at 43. At 60 it is seventeen seconds old. Seventeen is less than sixty, so it is fresh.” The final comparison follows from the student’s stated age, but the age omits inherited history. Start the repair at that omission.

A second response says: “Apparent age is 43 and corrected Age 45, so initial age 88.” Here the event inputs are correct; the combination operation is wrong. Ask whether the two numbers describe successive pieces of time or alternative estimates. Then restore the maximum selected by the exercise.

A third response computes 62 correctly and concludes that the response must be deleted. That moves beyond the calculated result. The age test says the response is not fresh under the supplied lifetime. Deletion, validation and any allowed stale reuse are separate matters.

Good feedback is specific: retain correct event labels, repair the operation that changed meaning, then revisit the final claim. Rewriting the entire solution as wrong hides useful evidence of what the learner already understands. Once the repaired ledger is secure, remove the prompts and ask for the independent case from the previous chapter with different numbers.

Contents · Previous chapter · Next chapter

Does a cache hit prove that information is current?

It identifies a cache outcome under the relevant system’s meaning. It does not alone establish editorial accuracy, the selected variant, or the entire age-and-reuse decision. Ask what the label actually records.

Why can the age estimate exceed time since Date on our clean timeline?

Our chosen conservative route can let incoming Age plus the receiving request’s delay dominate the apparent-age subtraction. The worked example deliberately preserves that estimated value instead of forcing a physical-stopwatch interpretation.

Is Age the same as time since the document was written?

No. The HTTP response metadata and the facts inside its body describe different things. A notice’s authoring or review history needs its own evidence.

Does an expired freshness test mean the response is unusable forever?

No. The complete protocol includes validation and bounded circumstances for stale service. This lesson isolates the age comparison and does not prescribe a production reuse policy.

What should I check before blaming a cache layer?

Identify the response and variant, the actual events, applicable lifetime, chosen age route, validation history and other reuse rules. Missing evidence should remain marked as missing.

Contents · Previous chapter · Next chapter

For the immediate numerical foundation, use the Websites subject guide alongside the CDN Mathematics guide. The first keeps the visitor’s whole task in view; the second connects caching with latency, keys, hit ratios and origin work.

For language and operational distinctions, the CDN caching and purge localisation guide separates protocol tokens, status labels, variants and purge scope. For maintaining content, follow preserving editors' accepted work and keeping section links meaningful when chapters move.

The authoritative protocol route is RFC 9111. Read the surrounding conditions when using its rules beyond this bounded paper exercise. The examples here supply invented timelines, not implementation certification.

Return to The Gold Standard of Education and How X Works to carry the broader skill forward: name each quantity, preserve its history, choose operations from meaning, and make the final claim fit the evidence.

Contents · Previous chapter · Return to Websites