- From: Mark Nottingham <mnot@mnot.net>
- Date: Tue, 10 Nov 2015 09:36:15 +1100
- To: Kenji Baheux <kenjibaheux@chromium.org>
- Cc: Amos Jeffries <squid3@treenet.co.nz>, ietf-http-wg@w3.org
Hi Kenji, > On 29 Oct 2015, at 1:33 pm, Kenji Baheux <kenjibaheux@chromium.org> wrote: [...] > ... 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. ... and later: > The only difference was to put a limit (once) on how often an implementation can use a stale asset. I'm not seeing how stale-once gives you what you want. Both SwR and SO have the potential to use an asset that's extremely stale (depending on how they're used). SO doesn't seem to mitigate this risk, especially in browser caches, where as you point out, there's only one user generating traffic. [...] >> 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. As Amos says, the SHOULD is strong. [...] > 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. I think so. While technically they could, they'd be operating against the intent of 5861, and probably violating that SHOULD. > Maybe we just need a minor update to RFC 7234 to make that clearer? If anything, I'd say 5861 would be where you'd look (e.g., to make it clearer that it isn't license to serve stale content for the full term without trying to revalidate). Cheers, -- Mark Nottingham https://www.mnot.net/
Received on Monday, 9 November 2015 22:36:50 UTC