Re: Cache varying on particular cookies

[Mark Nottingham <[e-mail]>]

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?
> 
> 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/