Re: Feedback about stale-while-revalidate

Thanks Amos for the feedback.

One thing I forgot to highlight: there is a key difference between s-w-r at
the User Agent (browser) level and at a Cache (server) level.


   - A Cache sees a lot of traffic which increase the likelihood of async
   revalidations even with short s-w-r values.
   - A User Agent only sees the traffic of its sole user which
   significantly decrease the likelihood of async revalidations for short
   s-w-r values.



> > *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.
>
> "SHOULD attempt to revalidate it" is strong language. It requires a very
> good reason not to do the revalidation.
>

The trouble here is from whom standpoint the assessment is made.


SHOULD: This word, or the adjective "RECOMMENDED", mean that there may
exist valid reasons in particular circumstances to ignore a particular
item, but the full implications must be understood and carefully
weighed before choosing a different course.



*Here are some specific examples we discussed:*

   - "This user is on a prepaid data plan, I could save him some data by
   not doing the async revalidations".
   - "I don't have enough confidence about this asset being used before
   max-age + s-w-r, so I could save some power by not doing the async
   revalidations"
   - "The user just swiped away the tab, I should probably cancel active
   and pending async revalidations"

"These seem like valid reasons from the User Agent viewpoint (it's good for
the user experience) and the spec says 'the server must be able to tolerate
the response being served from cache for up to [max-age + s-w-r seconds]',
so these seem fairly low risk".

If these are actually deemed valid reasons, then s-w-r lacks the guarantees
our partners need to pick large enough s-w-r value to make a difference for
s-w-r at the User Agent level. They don't want to run the risk of extending
max-age by a fair bit for some potentially large number of users.




> > *Concession*
>
> "concession" is a fighting term.
>

There was no fighting. Is "accommodation" better then?


Who are fighting here? and which party is so graciously granting their
> opposition a concession?
>

Friends from Ads and Analytics at Google (again no fighting involved).
I expect the same kind of dialogue from other Ads & Analytics third parties
but can reach out to confirm.


> 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).
> >
>
> I believe that requirement already does exist for caches complying with
> RFC 7234.
>
>
> RFC 7234 already requires in section 4.2.2:
> "
> A cache MUST NOT use heuristics to determine freshness when an
> explicit expiration time is present in the stored response.
> "
>
> The existant max-age=N is just such an explicit expiration time.
>
>
> Then in section 4.2.4:
> "
> A cache MUST NOT send stale responses unless it is disconnected
> (i.e., it cannot contact the origin server or otherwise find a
> forward path) or doing so is explicitly allowed (e.g., by the
> max-stale request directive; see Section 5.2.1).
> "
>
> The ability to revalidate implies that the cache is not disconnected.
>
> The stale-once definition does not provide an explicit allowance to
> serve stale content, only a guidance of how to act when stale is served.
>
> Thus the behaviour being proposed is already existing practice for RFC
> 7234 compliant caches. Unless they are explictly within one of the known
> cases where a revalidation or new fetch are not possible.
>
>
I assume that this means that all of the examples I mentioned above would
run afoul of RFC 7234 and would therefore not be allowed.

In which case, there is probably no new "valid reasons" for s-w-r that
don't already exists for max-age. In other words, the guarantees on s-w-r
as of today are strictly identical to those that exists for max-age. Is
this a correct assessment?




> stale-while-revalidate also has a delta-seconds parameter for how long
> the stale content may be served before it reverts to the behaviour of
> waiting for fresh content to be available. Which appears identical to
> the proposed stale-once= delta-seconds meaning.
>

Yes, indeed.
The only difference was to put a limit (once) on how often an
implementation can use a stale asset.



> > 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*.
>
> So what happens when a second display/fetch needs to happen during the
> revalidation RTT ?
>
> I see no reason to add latency to further deliveries is that one RTT
> happens to be long. Doing so would likely make the situation worse as
> service fluctuates between fast (but stale) and slow responses.
> Potential client recovery or retries of the slow responses causing the
> server to get more overloaded in a downward spiral.
>

Great point. We also a had similar question in User Agent land with
multiple tabs involved.



>
> And what happens of the cache is disconnected, or the client explicitly
> mandated that it will only accept the cached content?
>

Fair point, I oversimplified.

My conclusion so far is that thanks to RFC 7234, we don't need to worry
about s-w-r implementations turning max-age + s-w-r into the defacto new
max-age by default. Maybe we just need a minor update to RFC 7234 to make
that clearer?