Repository navigation
Warning: header & stale-while-revalidate #913
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?
Activity
wanderview commentedon Jun 24, 2019
It seems there was at least some kind of problem with the warning header:
https://tools.ietf.org/html/draft-ietf-http-warning-00
Is it one of those things that was never actually implemented in practice?
mnot commentedon Jun 24, 2019
It is; we downgraded it to a SHOULD in RFC7234, and are removing it in the next revision of HTTP. See httpwg/http-core#139
mnot commentedon Jun 24, 2019
BTW, if browser caches generated
Agecorrectly, you could see for yourself if it was stale or not. See: https://cache-tests.fyi/?id=other-age-gen&id=other-age-update-expires&id=other-age-update-max-age#annevk commentedon Jun 27, 2019
@whatwg/documentation given the upcoming changes to HTTP let's remove this from MDN or at least make it clear it's about to be obsolete?
chrisdavidmills commentedon Jun 27, 2019
@annevk I added a note at the top of https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Warning to cover this; does this read OK?
Also, the compat-data for Warning says that it is supported everywhere, but this thread and httpwg/http-core#139 make me think that is not entirely accurate. I wonder if I need to at least add a clarifying note in the data to. clarify how useful it actually is?
annevk commentedon Jun 27, 2019
If you have the equivalent of "blame" it'd be interesting to know why the person adding that data thought supported everywhere was applicable here.
chrisdavidmills commentedon Jul 2, 2019
@annevk yeah, I'm not sure who did that. What do you think I should say in the compat-data.
annevk commentedon Jul 3, 2019
I'm not sure and it might be a more general problem, as browsers don't support https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Accept-Charset either.
Accept-Charsetis only supported in the sense of not being able to set it fromfetch()and the browser not doing anything funny if it appears in a response. So again, it really comes down to the criteria of what makes a supported HTTP header. I suppose I'd say "no" for both and only use "yes" if there's some processing model in place that is also supported as is the case forCache-Controlfor instance (with caveats, as documented on that page).