Re: No-Vary-Search

On Wed, Mar 13, 2024 at 11:11 PM Mark Nottingham <mnot@mnot.net> wrote:

> Hi Jeremy,
>
> I don't think we've talked about it formally in the HTTP WG before, but
> some folks might recall that No-Vary-Search was discussed at the last HTTP
> Workshop:
>
> https://github.com/HTTPWorkshop/workshop2022/blob/main/talks/no-vary-search.pdf
>
> I personally think it would be good to do this work in the HTTP WG,
> because it's not just browsers that want to do this -- it's also a common
> use case for proxy caches and CDNs. However, the interaction with being
> able to store more than one variant (which browsers currently don't do)
> needs to be thought through.
>

While one variant would be more typical, the implementation in Chromium's
prefetch cache is compatible with there being multiple stored -- though of
course proxy caches and CDNs are still likely to have a larger number of
variants.

If we were to implement No-Vary-Search in Chromium's disk cache, yes, I
believe our current cache architecture would pose some challenges.


> *chair hat on*
>
> We've got a pretty tight agenda in Brisbane, but if you're interested, we
> might be able to squeeze in 5-10 minutes for a _very_ quick overview
> followed by discussion. Please tell us if you'd like to try.
>

Unfortunately it is not possible for me to join personally (time zones and
personal complications). We might be able to brief a Chrome team member who
is attending if there is interest (depending when this is), though as you
point out it would necessarily be a fairly brief overview on short notice
(so it might not be possible).

Whether or not that happens, I'd be interested to hear what other folks
> think.
>
> Cheers,
>
>
>
> > On 21 Feb 2024, at 13:08, Jeremy Roman <jbroman@chromium.org> wrote:
> >
> > Hello HTTPWG:
> >
> > This is tangentially unrelated to my previous email, but I've split it
> into another thread to avoid entangling the two.
> >
> > A developer previously reported to us that their ability to use the
> prefetch cache was limited because their prefetch request URLs needed to
> include certain query parameters which are different from the navigation
> request URL, even though these URLs do not affect the resource the server
> ultimately produces (and therefore, the client can safely use the
> resource). The explainer we wrote goes through some of the possible use
> cases in more detail.
> >
> > The semantics we have right now (and the header name, No-Vary-Search¹)
> are designed with the concept of being implementable in non-browser HTTP
> implementations, but since browser use cases were what we are focused on,
> there are some places where the semantics rely on, e.g., WHATWG URL, which
> may vary in subtle ways from other concepts of the meaning of the query
> string (since IETF HTTP doesn't currently take a position on that as far as
> I know).
> >
> > The specification draft is currently hosted by the W3C's Web Incubator
> Community Group (WICG) and we've previously discussed it in a W3C context,
> but it was suggested that we bring it to HTTPWG's attention, too, and if
> there is interest among participants it could migrate to an HTTPWG RFC
> instead of continuing incubation in the web standards venues.
> >
> > ¹ This was originally No-Vary-Query, but the web-exposed APIs call this
> part of the URL "search", so this change was requested in a W3C discussion.
>
> --
> Mark Nottingham   https://www.mnot.net/
>
>