Re: [w3c/ServiceWorker] Scope matching algorithm breaks sites that don't end in a slash (#1272)

@jakearchibald: I think you're fixating on the Maps example too much. Yes, Maps is a mess because they have like 40 non-structurally-related URLs that all redirect to the same domain, and there's not much we can do about it. But a path without a slash being a parent of a path with a slash is universal.

> `/foo` and `/foo/` are different URLs, and may serve different content. One redirecting to the other is something the server is choosing to do, it isn't a web standard. We should be mindful of that.

Yes, they are different URLs; redirecting one to the other is a convention, not part of a standard. Note that I am not proposing that they be treated equivalently, or an automatic redirect, but a sensible containership rule.

`/foo` *is* a parent of `/foo/` and `/foo/*`(proof: `/foo/..` canonicalizes to `/foo`), while `/foo` is a sibling of `/foobar`. Therefore, if you are going to define a URL-based "containership", it makes sense to be able to create a containership boundary that includes `/foo`, `/foo/` and `/foo/*` (all of which are equal to, or are descendents of `/foo`), but excludes `/foobar`. That currently isn't possible for SW or Manifest scope.

If this is not possible for breakage reasons, I'd like for it to at least be possible to define this boundary. I agree that making scope `/foo/` include `/foo` would be unsatisfactory, but it may be the simplest way to design out of this hole we seem to be in. Although perhaps @slightlyoff's suggestion to simply have an opt-in to "correct" behaviour (path-component prefix, not string prefix) is better, because then it avoids the issue of slightly widening the scope, and doesn't change any existing behaviour.

> Install a service worker at `https://maps.google.com/maps` that redirects to `https://maps.google.com/maps/` as long as the path exactly matches.

Having the two service workers doesn't buy you anything at all, since you still end up with a SW that handles all URLs that start with `/maps`, so you still need to install a competing blank SW to cancel out the `/maps` one. You may as well just have your main SW scoped at `/maps`.

> If `https://maps.google.com/mapsearch` becomes a thing, they can install their own blank service worker if they want to avoid the startup cost of the `https://maps.google.com/maps` service worker.

This is not a great solution. Again, this is not a Maps-specific quirk. This affects 100% of SWs that aren't installed at the origin root. Should all such sites be required to install a dummy SW at any paths that share a string prefix with another SW, just because the scoping rules are broken?

Also, this solution doesn't work for Web App Manifest (which suffers the same issue, on account of consistency with the SW spec), because unless the user has installed the `/mapsearch` app, those URLs would be handled by `/maps`.

Whether it's opt-in or default behaviour, I would really like to see a solution that makes it *possible* to define a sane scope that includes slashless paths.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/ServiceWorker/issues/1272#issuecomment-364808783