Revalidate without holding up the reader
02A request during the stale window can receive old content immediately while the cache checks the origin in the background.
This example’s validation succeeds. The earlier stale reply remains marked as earlier; later responses follow normal cache handling.
Source for this drawing: RFC 5861 · Read RFC section 3.1 ↗
New to this? Start hereA quick picture + helpful background
A message needs an address.
Think of a packet as a small addressed envelope. Devices pass it onward; transport protocols decide what delivery promises an application gets.
Helpful first, if these ideas are unfamiliar
These pictures are analogies to help you learn. The linked RFC explains the actual rules.
Terms in this drawing
- Revalidation
- Checking with the origin whether a stored response can still be used.
- Origin
- The server responsible for the requested resource.
- Background
- Work that does not make this stale response wait for completion.
Related RFCs and changes
“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.
Background validation is driven by demand, not a promised refresh timer.
- If a cache serves stale because of stale-while-revalidate, it SHOULD attempt revalidation without blocking the stale responses it serves.
- Asynchronous validation happens only if a request arrives after expiry and before the window ends. Sparse traffic can miss the window; this directive does not guarantee every request avoids delay.
- Section 5 suggests predicating background validation on an incoming request to avoid amplification risks from unsolicited refreshes. This is security advice, not a new capitalized MUST. Successful validation ends this stale-while-revalidate episode; subsequent use follows normal cache rules.
Chosen example: Age 610, max-age=600 and stale-while-revalidate=30. The client’s GET triggers this cache’s background work. A stale 200 reply and the origin validation are concurrent branches, not a requirement to wait for the origin first. The last scene assumes successful validation; it does not promise a new 600-second lifetime, a particular status code, or periodic prefetching.
Read the RFC section ↗