Description
While investigating the history behind the stale-while-revalidate Cache-Control option, I found that the original description in RFC5861 included the following:
If a cached response is served stale due to the presence of this extension, the cache SHOULD attempt to revalidate it while still serving stale responses (i.e., without blocking).
Note that "stale" implies that the response will have a non-zero Age header and a warning header, as per HTTP's requirements.
(I am not familiar with the story behind that RFC, but what I've gathered from talking informally to some folks is that it might have been geared more towards caching proxy providers and less towards the browser user agent use case.)
I believe that the warning header referred to there is the same thing as what's documented on MDN, and might look something along the lines of Warning: 110 <warn-agent> Response is Stale [<warn-date>]
The Fetch Standard now includes a section about stale-while-revalidate responses, but there's no mention of the Warning: header in that text. Chrome and Firefox both have implemented stale-while-revalidate, and in their implementations, there's no Warning: header present on the Response object when a stale response is used.
(https://glitch.com/edit/#!/s-w-r-demo is a really basic web app + server I put together to try this out.)
As a developer, I'd find information that would theoretically be present in a Warning: header to be useful, and I am curious whether its omission from the Fetch Standard was intentional or not. If it was intentional, and if RFC5861 is still relevant, then perhaps it should be marked as a willful violation?