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