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

`/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.

`https://www.google.co.uk/maps` doesn't redirect to `https://www.google.co.uk/maps/`, but both serve the same content. If the page contained a relative link to, say, `cat.gif`, that URL would resolve to a different place on each page, as link path resolving doesn't auto-add `/`. Is there any web standard that does the kind of magic we're thinking about? Doing something different to links seems weird.

`https://maps.google.com/` exists. It redirects to `https://maps.google.com/maps`. `https://maps.google.com/` has the same offline linking issues as `https://maps.google.com/maps`, but none of the proposed scope changes fix that issue.

`http://maps.google.com/` also exists, and doesn't appear to use HSTS.

`maps.google.` + loads of TLDs exist. As does `https://maps.google.[load of TLDs]/maps`.

There's a lot of hate for scope from standards folks, but remember that it's what allowed developers to use service workers on github pages, rawgit, WPT, and `/~username/` servers. It also allows developers to have a different SW for push vs fetch. An origin per app is of course the ideal, and sub-origins are an interesting workaround where a genuinely different origin can't be used.

It feels like the best short-term solution is:

Add HSTS to `http://maps.google.com/`, so users are redirected to HTTPS even when offline.

Install a service worker at `https://maps.google.com/` to redirect to `https://maps.google.com/maps/`. This is a good argument to bring back the `Link: rel=serviceworker` header, as the service worker could be installed when the URL is hit. As a workaround, an iframe pointing to `https://maps.google.com/install-sw` could be used on `https://maps.google.com/maps/` to set this up, but this may hit double-keying complications in Safari.

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.

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.

The `https://maps.google.com/maps/` service worker contains the maps logic.

I don't have a good solution for the multiple TLDs. To fix that we'd need a way to scope a service worker to something greater than an origin, like a cert. Ew.

The above is complicated because maps doesn't really have a canonical URL. They have `maps.google.` * TLDs * 2 (for http/https) + (`maps.google/maps` * TLDs) + (`maps.google/maps/` * TLDs).

Is this a mess that service worker should be trying to fix?

-- 
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-364445866