Feedback about stale-while-revalidate

Hi,

I'm Kenji Baheux, working on Chrome at Google.

The Chrome team has been looking into supporting stale-while-revalidate
<https://tools.ietf.org/html/rfc5861> (s-w-r for short) in the user agent.
While discussing the feature with various parties, we felt that there was a
mismatch between the spec and their requirements.

I talked about this with Mark while at TPAC and he suggested that I start a
thread in this working group.

*For background:* our interest in the feature is motivated by the desire to
remove HTTP revalidations from the critical path. In particular, our
attention has been on third parties (ads, analytics, web fonts, social...)
because of scale and because of common characteristics:

   - third parties assets tend to block rendering (e.g. script and
   stylesheet in the head)
   - third parties assets tend to have very short max-age (e.g. 15-30
   minutes is common)
   - third parties tend to be hosted at a unique origin making the cost of
   setting up a connection particularly prohibitive on mobile.


*The mismatch*
The spec doesn't impose any strong requirements on the need to perform
async revalidation during the s-w-r window. In fact, it allows for an
implementation to use a stale asset for up to max-age + s-w-r seconds.

For business reasons and the potential risk of breaking the publisher's
website, most third parties are opting for a very short max-age to
guarantee a short time to recovery. Actual example: max-age=900 (15
minutes).

To avoid more frequent revalidations from user agents who don't support
s-w-r, max-age must be kept roughly the same.

To maintain a similar guarantee of time to recovery, s-w-r would only be
used with a tiny window (e.g. a couple of minutes). Unfortunately, this
greatly limits its effectiveness, esp. on mobile considering common usage
patterns: short sessions with gaps of several hours. Example: max-age=900,
s-w-r=60.


*Concession*
If it was guaranteed that an async revalidation MUST be performed in order
to use a "semi-stale" asset, effectively turning the time to recovery to
max-age + 1 use, our interlocutors felt they could use a larger s-w-r
window. Example: max-age=900, s-w-r: 86400 (1 day).


*Strawman proposal*
Option 1: revising the semantics (see below) of s-w-r.
Option 2: introduce a new extension (see below)


Cache-control: max-age=900, stale-once=86400

When present in an HTTP response, the stale-once Cache-Control extension
indicates that caches MAY serve the response in which it appears after it
becomes stale, up to the indicated number of seconds but *only once*.

     stale-once = "stale-once" "=" delta-seconds

If a cached response is served stale due to the presence of this extension,
the cache *MUST attempt to revalidate* it while serving the stale response
(i.e., without blocking).

Note that "stale" implies that the response, if coming from an intermediate
cache, will have a non-zero Age header and a warning header, as per HTTP's
requirements.

If delta-seconds passes without the cached entity being revalidated, or if
the cached entity *has already been served stale once*, it *MUST NOT
continue to be served stale*, absent other information.



Looking forward for the feedback of the working group and other potential
users of such a feature.

PS: the Chrome team is still considering running an experiment with the
existing semantics in order to gather concrete data about the benefits. I
will happily share as we learn.