Re: Cache varying on particular cookies

[Robin Marx <[e-mail]>]

Hello Jeremy,

I'm part of the team at Akamai behind the "awkward workarounds" post you
shared :)
We obviously also agree something like this is needed and would like to
collaborate both inside and outside of the IETF to further this.

We were originally also looking mostly at the Availability Hints draft, but
see there's also ongoing work around "cache groups" (i.e.,
https://www.ietf.org/archive/id/draft-ietf-httpbis-cache-groups-01.html).
This seems like a potential alternative; if affected pages for example by
default get a cache-group of "not-logged-in" and then the server
sends Cache-Group-Invalidation: "not-logged-in" upon successful login, this
might give the expected behaviour
(though, arguably, in a workaround-y way maybe? and it seems some normative
language in the current draft maybe isn't optimal for this use case).
It might also run into similar performance issues as we've seen with
Clear-Site-Data: "cache" (see
https://calendar.perfplanet.com/2023/rli/#clear_site_data_header), but
still, a potential alternative to consider.

Potentially we might prepare something to present at IETF 120 to help
further discussion / bring it to the wider wg's attention?

With best regards,
Robin


On Thu, Mar 14, 2024 at 4:18 AM Mark Nottingham <[e-mail]> wrote:

> Personally, I'm supportive, but that's probably not surprising :)
>
>
> > On 21 Feb 2024, at 13:08, Jeremy Roman <[e-mail]> wrote:
> >
> > Hello HTTPWG:
> >
> > I'm working on speculative loading in Google Chrome (most saliently,
> prefetch of documents for navigation) and looking at ways to address the
> potential problem of prefetched resources becoming "stale" by the time they
> are used due to the user logging in or out (or similar state changes), in
> response to developer feedback. Workarounds are possible but somewhat
> awkward.
> >
> > Fundamentally it seems like something less strict than "Vary: Cookie" is
> called for, which would let the client know which cookie values, if
> changed, invalidate the cached resource. The semantics of this seem
> potentially useful for other kinds of cache (e.g., some caching proxies can
> be configured to work this way), so HTTP WG seems like potentially the
> right venue to discuss this.
> >
> > Mark Nottingham's Cookie-Indices proposal (part of HTTP Availability
> Hints) seems likely to address the problem and ought to be implementable
> (I'm prototyping it in Chromium's prefetch cache, at least), so that's what
> I'm looking at right now, but at this moment we're not yet committed to a
> particular solution.
> >
> > What do you all think?
>
> --
> Mark Nottingham   https://www.mnot.net/
>
>
>

-- 
Marx Robin
[phone]