Summary

  • RFC 5861, published in May 2010 as an Informational Independent Submission, described two separate permissions: stale-while-revalidate for an old response during background checking, and stale-if-error for an old response when an error would otherwise reach the client.
  • Its examples make the clocks concrete. max-age=600, stale-while-revalidate=30 allows a ten-minute fresh period and a possible thirty-second stale interval; max-age=600, stale-if-error=1200 can turn a failed origin check at age 900 into a cached 200 with Age: 900.
  • RFC 9111, published in June 2022, retained explicit permission as the boundary for serving stale HTTP responses and obsoleted the old Warning field. Age still tells the reader how long the representation has gone since origin generation or successful validation.

The old answer arrives before the new one

A cache exists to avoid repeating work. A stored response is fresh for a period chosen through HTTP caching rules, often by the origin server. Once that period expires, ordinary reuse calls for validation or another response. The waiting can add network and server time to a request that only wanted a page already sitting nearby.

RFC 5861 offered a limited trade. An origin could send Cache-Control: max-age=600, stale-while-revalidate=30. The first 600 seconds give the cache a fresh response. During the next 30 seconds, a cache may hand out that now-stale response while it asks the origin in the background whether the copy is still current. The reader gets the old page quickly; the origin check runs behind the curtain. If validation succeeds, later readers receive the updated freshness state or a replacement.

The interval has an edge. The 2010 RFC says that if validation is inconclusive, or no traffic arrives to trigger it, the stale-while-revalidate window ends after those 30 seconds. The next request then waits for normal handling. The feature hides latency only when a request lands in the short window and can set validation in motion. A quiet page with few visits may get little benefit. The old copy is licensed for a bounded interval, not made fresh by a clever name.

That timing changes the origin's decision. A publisher can set both the ordinary lifetime and the extra stale window. A long interval gives clients faster answers over more time but delays the visibility of edits. The origin chooses how much change it can tolerate readers missing while the cache catches up. The cache decides whether to exercise the permission and how to run validation. A reader sees the result of both choices.

The 500 that the reader did not see

The second extension, stale-if-error, addresses a different failure. The cache tries to reach or validate against the origin, and the attempt would produce a server-side error. RFC 5861 names situations that would yield 500, 502, 503, or 504. Within the allowed stale interval, the cache may use its older stored response instead. The origin has failed to supply a current answer; the reader receives an earlier success.

The RFC's worked example starts with a response marked max-age=600, stale-if-error=1200. It is fresh for ten minutes. At age 900 seconds, the cache encounters a 500 Internal Server Error. It can return the stored 200 OK body with Age: 900. The response looks successful at the status line because the cached representation succeeded earlier. The Age field exposes that the answer came from storage and has had time to age.

The second number is not an endless emergency power supply. The old success can be served for up to 1,200 seconds beyond its fresh lifetime. At total age greater than 1,800 seconds in the RFC example, the error must be passed through. The point of the limit is operational: a site may prefer an older page over a hard outage for twenty extra minutes, while refusing to let a week-old page keep masquerading as today's service.

stale-while-revalidate and stale-if-error thus make different bargains. The first trades a little freshness for lower waiting time while an origin check proceeds. The second trades freshness for continuity when that check fails. One depends on a background validation attempt during a short grace period; the other depends on an error condition and its own maximum stale age. Combining their names into a generic “serve old content” setting would hide who authorized which situation and for how long.

The warning label itself was retired

The 2010 document expected stale responses to carry a nonzero Age and a Warning field under the HTTP rules then in force. The later RFC 9111 kept the logic of bounded stale use but retired Warning: it said the field was not widely generated or shown to users, and its information could be inferred from other fields such as Age.

The change is a small piece of Internet history with a large practical consequence. A reader or operator looking for a conspicuous “stale” label in current responses may be searching for a field the current caching standard has dropped. Age reports an estimate of time since origin generation or successful validation. Cache policy and validators explain why a stored response was usable. The status line by itself can say 200 even during an origin failure, as the RFC 5861 example shows.

RFC 9111 also sharpened the permission boundary. A cache cannot generate a stale response when an explicit directive such as no-cache or must-revalidate forbids it. Otherwise, stale use needs an eligible condition: disconnection, express permission from client or origin such as RFC 5861's extensions, or an out-of-band contract. The origin can grant a bounded exception; it can also forbid one. The cache is an intermediary with discretion inside those limits, not the owner of every resource's freshness policy.

The price of a fast, successful old answer

RFC 5861 was an Informational Independent Submission, rather than an IETF Standards Track document. Its two controls nonetheless became explicit examples in the 2022 Standards Track caching specification's account of when stale responses may be served. That sequence records the idea's place in HTTP's permission model. It does not count how many caches deployed it. Dated response headers, cache configurations and origin-failure captures would establish which operators used the controls in practice.

The mechanism carries a sharp trade. An old page can be the better service when the origin is slow or broken, especially for information whose next edit can safely wait. The same old page can be dangerous when its contents direct a payment, an access decision, or another action that cannot tolerate stale state. The origin sets a time allowance based on the cost of delay versus the cost of old information. The cache spends that allowance on behalf of readers, sometimes returning a clean 200 while the origin is on fire.