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

> `/foo/..` canonicalizes to `/` I believe.

Of course, what was I thinking. OK, I withdraw this; there is no "internal" argument (in URL syntax) that `/foo` is a parent of `/foo/`. However, I still think most developers and users would consider things inside `/foo/` to be contained within `/foo` (i.e., `/foo/` is not a sibling of `/foo`, unlike `/foot` which is).

Ultimately, this all goes back to the Unix file system, where `mv /foo <dest>` will move not only `/foo` but everything inside it. But it won't touch `/foot`. It would be *very* surprising if `/foo` meant the same thing as `/foo*`.

> > You may as well just have your main SW scoped at `/maps`
>
> But then you have app logic in the SW that may also control `/mapsearch`. A simple redirect is less likely to be an issue.

>From the point of view of which URLs are captured by SWs, having two SWs instead of one doesn't change things. Either way, you still need a third SW (what I'm going to call an "anti-service-worker" since it exists solely to poke a hole in the parent SW) in `/mapsearch` and every other path that starts with "maps".

> > I would really like to see a solution that makes it possible to define a sane scope
>
> I think it's a bit much to imply the current scoping rules are 'insane'. Can we tone down the rhetoric, please?

Well, I used the word "sane", which sounded softer in tone (to me) than explicitly calling the current behaviour "insane".

> Is that a fair description of the problems?

Yes, but I believe not all three problems are equally valid. I think Problem 1 is something SW scoping should handle, Problem 2 is a maybe, and Problem 3 is out of scope. I'll try to justify this, but if nothing else, as @davidcblack says, because each problem is significantly harder to solve at the spec level than the last, and if we can easily solve Problem 1, we shouldn't stop because we can't solve the others.

The reason to favour solving P1 is:

- P1 is, I would consider, a basic expectation, that I can define a scope including a particular directory name and its children, without capturing some of its siblings.
- P2 is perhaps a problem for certain sites (notably, Google Search whose URL is a parent of many other Google properties), but I'd say there's less of an expectation that I can define a scope that includes `/foo/` and everything inside `/foo/` except `/foo/bar`. If you need so solve P2, your URL hierarchy is "too complex".
- P3 is a problem for a lot of sites, but I wouldn't expect a solution from the web platform. It raises basic issues of ownership. If I own "mysite.com", there's no guarantee that I own "mysite.com.au", and I wouldn't have any expectation that mysite.com could claim the scope of mysite.com.au into its SW. Also, P3 is something a developer can solve themselves (by adding a SW to the other origins), while P1 is not solvable unless you add explicit "anti-service-workers" in all of the other directories that have the same prefix.

Ironically, there seems to have at one point been a "Problem 0": defining a scope that includes several sibling directories that start with a common prefix. I consider that way down on my list of "must have" features of a scope matching algorithm, and can't think of any use case for it. Yet it seems to have been prioritized over Problem 1.

> Also, although problem 3 is real-world and creates the same user experience issues as 1 & 2, are we happy to WONTFIX that? If so, why are we less bothered about that case?

I don't agree it creates the same UX issues. First of all, P3 is solvable by the developer, while P1 is not (unless they do the whole "anti-service-worker" trick, and make sure any future developers who play in the same URL space do the same).

Secondly, as a user, I barely notice the trailing slash. In fact, I think most users (who know what a URL is at all), and heck probably most developers, think that a trailing slash is semantically identical to not having it (i.e., that "google.com/maps" and "google.com/maps/" are the same URL). I was certainly under that impression for a long time. So it's quite unintuitive if a user types "google.com/maps" and it doesn't load, and then they are told, "oh, you need to add a trailing slash for it to work offline." On the other hand, anyone can tell that "maps.google.com" and "google.com/maps" are different addresses. Even if people can't tell you the difference between them, and they seem to both work the same, you can understand if you're told, "maps.google.com" is a web page that bounces you to "google.com/maps"; even though "google.com/maps" works offline, if you type "maps.google.com" you need to be online for it to work.

The possible solutions:

- S1 is not really acceptable, as you point out.
- S2 and S3 are really complex, introducing a bunch of gotchas and questions that you raise. They might help to solve P2 and P3, but I don't think they are crucial.
- S4 solves P1.

> However, this is kinda magic

I don't get why matching path segments is "magic". If scope *always* matched path segments, would you consider it magic? In other words, is the "magic" the path matching algorithm itself, or the fact that it's something the developer has to opt into?

If the former: ... why? Matching path segments is the basic way of telling if one URL (or Unix path) is a prefix of another.

If the latter: I agree, it sucks that you'd have to opt in to getting the "right" behaviour. But the ship has sailed on having the right behaviour by default. I'd rather tell web devs, "use this flag to opt in to path prefix" than "make sure every URL that ever starts with the four letters 'maps' registers a blank service worker."

Now I've finished every email to this thread mentioning Web App Manifest and nobody has responded about it. I'd like to have the same scope matching solution for both SW and Manifest. I'm happy if we come to the conclusion that they have different requirements and should therefore go in separate directions on this. But I think it would be best if there is a consistent approach for both. (Note: I am not really invested in Service Workers here; I'm just trying to ensure consistency between the two specs, since the Manifest spec [explicitly cites the SW spec](https://www.w3.org/TR/appmanifest/#navigation-scope) for why it has this behaviour.)

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