Stale-While-Revalidate: What Happens During the Cache Revalidation Window

The proposal comes to mind because, in practice, the configuring of grace windows is not as simplistic as it might appear. A well-tuned length guards against cache misses and updates while risking stale read impacts.

What the Directive Authorizes

In the most basic sense, stale-while-revalidate allows a cache to serve a stale response to client requests, while making a revalidation request to the origin in the background, per its definition in RFC 5861. Specifically, the spec states that when the directive is present, caches MAY serve the response after it becomes stale, up to the indicated number of seconds 12. This is very much the stage where a fresh-to-stale transition hands back control, in agent terms, from origin to client.

The Split Between Fresh, Stale, and Rotten

The max-age directive defines the limit between what is considered fresh and stale. Responses older than the max-age must have their freshness validity and caching decisions adjusted, and revalidations are triggered at this point. The presence, or combination, of stale-while-revalidate and max-age therefore defines a timeline of fresh, stale, and rotten states. Surpassing stale-while-revalidate - and so leaving the window of stale content serving - means that the client response is counted by RFC 5861 as "rotten", not merely stale, and may not be reused.

This is a crucial concept, because once a resource is no longer considered stale, it can be cached again,.

While RFC 5861 defines background refresh, the gathered literary sources did not carry an implementation-specific affirmation that a cache automatically triggers revalidation on first request after max-age expires. More authoritative sources on browser or CDN mechanics would be required.[What happens on concurrent requests during revalidation?

During the stale window, the exact request-response sequence is important: the first request during the stale period triggers the revalidation process, while subsequent requests will still receive the stale content from the cache, at least while revalidation completes in the background. This behavior allows for faster responses to multiple clients while the background revalidation is ongoing. 212

The exact definition of the sequence for each concurrent request is not obvious, and was not explicitly covered in the gathered sources. Overlapping emphasis risks confusion, but it seems likely that a sequence similar to this applies:

1. The first request after freshness ends meets cache policy and triggers revalidation in the background.
2. The cache responds with the stale content.
3. Concurrent requests during revalidation also receive the same stale content912.
4. When the revalidation completes, subsequent requests receive the new, updated content from the origin.

The exact definitions for request definition, notification of concurrent refresh and client support for error codes are less clear.

Underlying browser and CDN support was not confirmed, with only broad support noted. Checking browser implementation documentation would give the primary-source differences between browser and CDN.

Error Fallback

Separately to staleness, RFC 5861 also defines stale-if-error, which allows a cache to rely on stale content even if an error occurs, such as a 500 Internal Server Error, network interruption, or DNS failure, as long as this exceeds the specified limit. The response then falls back to an error page, which could be custom, 500, or similar.

To summarize, stale-while-revalidate is about staleness while stale-if-error is about errors.

Browser Versus CDN Behavior

The gathered resources confirmed support across both browser and CDN, but stopped short of discerning the exact handling on concurrent requests_REF1112. Testing showed stale-while-revalidate working in Chrome Developer tools, but Safari debugging results were inconclusive.

To improve the reliability of this assertion, one approach would be to look for primary-source confirmation that CDN revalidation policy is distinct, such as asking Cloudflare or Amazon Cloudfront support. Safari debugging could also provide evidence but this would require new testing.

Conclusion

Removing the obligation for client-based handling is not without cost: stale-while-revalidate offers a window for stale content, as contrasted to the failover for errors in stale-if-error. Engineers should consider both behaviors when tuning cache performance and user experience. To determine the right window lengths, consider the likelihood of concurrent requests, expected freshness of the content, and the acceptable trade-offs between stale content and revalidation time.