No-Vary-Search can cause reserved client creation URL mismatch

[hiroshige-g]

When the prefetch is served using No-Vary-Search matching (which is not yet specified yet?), the navigation param's reserved client's creation URL doesn't match with the navigation URL.

For example,

• Prefetch /page?param=1. The server responds with No-Vary-Search: "param" response header.
• Navigate to /page?param=2. The prefetched response is served due to the No-Vary-Search header.

Then the resulting Window's settings object's creation URL is /page?param=1, because in the current spec it is derived from the prefetch's navigation param's reserved client.

The observable behavior change includes controlling ServiceWorker: if we register two service workers (that just fall back to the network) with scopes /page?param=1 and /page?param=2, respectively, which service worker should be the controller of the resulting page?
In the current spec, the controller would be the service worker with scope /page?param=1 (which is set during prefetch), and remains the same even after e.g. claim() (because settings object's creation URL itself is also /page?param=1), while it would be the service worker with scope /page?param=2 without the prefetch.

Candidate soloutions (just brainstorming, not yet sure at all):

• Just allow this mismatch. I feel the behavioral impact in the real world is more like theoretical (page authers can register a service worker controlling all URLs under No-Vary-Search matching and actually very likely do so). I'm not fully sure how the creation URL mismatch can affect things other than ServiceWorkers though.
• Fix the Window's settings object's creation URL only -- maybe relatively easy? and saves a little more consistency and the controller would be the service worker with scope /page?param=2 after claim().
• Also fix ServiceWorker controller (even before claim())? But this needs going through ServiceWorker registration lookup etc. again, and I have to plumb a new path to Match Service Worker Registration, and I'm not sure this isn't something that can be done very immediately (I'll try another iteration later).

[hiroshige-g]

@nhiroki @domenic FYI

[domenic]

Sorry for the delay in getting back to this.

When the prefetch is served using No-Vary-Search matching (which is not yet specified yet?),

I think it is specified: https://wicg.github.io/nav-speculation/prefetch.html#prefetch-record-matches-a-url

Then the resulting Window's settings object's creation URL is /page?param=1, because in the current spec it is derived from the prefetch's navigation param's reserved client.

I tend to think we should update this to be /page?param=2 at Window creation time, just based on the name.

Looking at webdex another impact is on referrer policy. I think /page?param=2 is more correct for referrer policy.

The other impacts I'm less certain about. E.g. cookie store API is not impacted by search, I think, only path. Memory measurement API might be making a mistake by using creation URL instead of API base URL or document's URL. Etc.

So in general I think I agree with

• Fix the Window's settings object's creation URL only -- maybe relatively easy? and saves a little more consistency and the controller would be the service worker with scope /page?param=2 after claim().

Regarding

Also fix ServiceWorker controller (even before claim())? But this needs going through ServiceWorker registration lookup etc. again, and I have to plumb a new path to Match Service Worker Registration, and I'm not sure this isn't something that can be done very immediately (I'll try another iteration later).

I think this is not necessary. If the prefetch is targeting the URL /page?param=1, it feels best to have the service worker with control over that scope be the one controlling the fetch.

But, maybe I am not understanding the full consequences of that.