RFC 5861 / START HERE
Stale Cache Controls, before the details
HTTP means Hypertext Transfer Protocol. Cache-Control is an HTTP field that supplies cache policy; stale means a saved response is no longer fresh.
RFC 5861 defines two independent controls: stale-while-revalidate can hide validation delay, and stale-if-error can use an older response during an eligible failure. Both have bounded time allowances.
The idea in one picture
An answer becomes stale
Check the permitted window
Revalidate or handle the error
A simplified picture of the idea; the chapters explain the actual mechanisms.
Why it exists
A cached answer can still be useful while a server checks for changes or recovers from an error. These directives permit selected stale reuse; they do not guarantee freshness, storage or availability.
A familiar example
A fictional forecast response is fresh for 600 seconds. At Age 610 it can be returned while a background check runs if stale-while-revalidate=30 applies. A separate stale-if-error=1200 policy can permit a stored success after a 500; it is not the same condition.
Helpful background
You can start here without reading another RFC. If these ideas are unfamiliar, these short introductions may help.
What you’ll learn next
Begin with chapter one, or choose a topic.
- Separate freshness from the stale windowAn extra stale-while-revalidate window permits limited reuse after normal freshness ends; it does not make old content fresh.→
- Revalidate without holding up the readerA request during the stale window can receive old content immediately while the cache checks the origin in the background.→
- Use stored success after an eligible errorstale-if-error can allow a cache to return stored content instead of an eligible failure, within a separate staleness limit.→
- Stop fallback when the allowance endsA stale-if-error limit measures time after freshness ends. A later failure beyond that allowance cannot use this example’s fallback.→
This introduction explains RFC 5861 (2010). Read the original RFC ↗