consider making service worker scopes only use pathname matching

[wanderview]

At the TPAC 2020 discussion @annevk suggested making service workers scopes only match against pathnames instead of the entire URL. This is related to the question of removing hostname matching in #19, but slightly different.

After thinking about the suggestion and what it would mean I am leaning towards doing this. My idea is to expose a separate interface:

let p = new URLPathnamePattern('/foo/*');
if (p.test(my-path)))
  // do stuff

It would also take a baseURL for relative pathnames:

let p = new URLPathnamePattern('./*', self.location);
if (p.test(my-path)))
  // do stuff

The full URLPattern and this URLPathnamePattern interface could share the same internal code for matching pathnames.

For lists we would need something like URLPathnamePatternList.

One notable change for the test() and exec() methods is they would no longer require a full parsable URL. Instead they would only require a pathname. For code that only has a pathname to begin with this would make the API easier to use instead of constructing full URLs just to wildcard all the non-path parts.

Service worker scopes would then take URLPathnamePattern or URLPathnamePatternList. This would cause service workers to lose the ability to match against any search string values, but I think we all agree that was an accidental feature and does not work well for real use cases.

My current plan is to prototype this kind of path-only interface in addition to URLPattern for use cases looking for full URL matching.

[kettanaito]

I'm sorry if I'm missing the context here, but wouldn't URLPathnamePattern behave the same as URLPattern without the baseUrl option set?

const a = new URLPathnamePattern('/foo/*')
a.test('/foo/bar') // true

const b = URLPattern({ pathname: '/foo/*' })
b.test('/foo/bar') // true

I think I may be misreading the intention behind the baseUrl here.

[wanderview]

You are correct. This issue was written before we settled on the final shape for URLPattern. We don't need to expose a separate URLPathnamePattern object since you can use URLPattern({ pathname: '/foo' }) as you say.

I tagged this issue as "service-worker" because the main decision here is about how we will integrate URLPattern with service worker scopes. For historical reasons thats mixed up in this URLPattern repo now. Eventually this will get moved into the service worker spec.

[sisidovski]

ServiceWorker Static Routing API provides a way to bypass service worker in some specific URLs in the registered scope.

If the scope pattern matching for the service worker registration is required for the bypassing purpose, it can achievable by the the static routing API. The example in the explainer describes how to bypass SW on pages in the scope.

I'll close this issue but feel free to reopen if needed.