Re: Cache varying on particular cookies

[Jeremy Roman <[e-mail]>]

On Fri, Mar 15, 2024 at 1:09 AM Mark Nottingham <[e-mail]> wrote:

> Hey Robin,
>
> I don't think that cache groups are a good solution for this, because they
> require a separate invalidation to be sent to the cache -- requiring not
> only latency but also for the origin to know where the cache is. The merit
> of availability hints in this situation is that all of the necessary
> information is already available to the cache.
>
> Cheers,
>
>
> > On 14 Mar 2024, at 20:08, Robin Marx <[e-mail]> wrote:
> >
> > 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?
>

Sounds reasonable; hopefully we're further along on the Chrome side, too,
by July.

> 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]
>
> --
> Mark Nottingham   https://www.mnot.net/
>
>