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

@mgiuca 

> Ultimately, this all goes back to the Unix file system, where mv /foo <dest> will move not only /foo but everything inside it

Yeah, but that isn't how URLs work. On the file system `/foo` can be a directory or a file, but you can't have one of each with the same name. URLs don't have the concept of directories.

> 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 agree it isn't a pretty solution, but we should compare the proposed solutions to it.

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

Fair enough. It felt implied to me. By wanting a "sane" solution, the implication is that the current solution isn't that, therefore "insane".

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

That was never a specific use-case. Prefix matching was chosen as it matches how URLs behave. Yes, there are conventions, but as we've seen with the maps example, some conventions are pretty weird, like serving the same content from multiple URLs.

> heck probably most developers, think that a trailing slash is semantically identical to not having it

Relative URLs behave quite differently.

> So it's quite unintuitive if a user types "google.com/maps" … On the other hand, anyone can tell that "maps.google.com" and "google.com/maps" are different addresses

Is typing URLs in full a use case worth considering? I don't think it is real-world these days. Users are clicking on links, icons, or relying on autocomplete in the address bar.

When I type "maps" into my URL bar, the first autocompletion offered to me is `maps.google.co.uk`. There's nothing here to tell me I'm picking the wrong URL if I want to work offline.

If a user clicks a link that points to `maps.google.co.uk` and it fails to load offline, do you really think they'll go "ahh yes this URL is wrong, I should correct it to `google.com/maps/`?

> I don't get why matching path segments is "magic".

Can you name another web API that treats `foo` as `foo/`? What would you call the option that enables this behaviour?

>  it sucks that you'd have to opt in to getting the "right" behaviour.

By "right" you mean differently to how every other web API treats URLs.

I'm a little confused that we've been presented with a series of real-life use cases, but now we're being asked to ignore some of them because a solution has been suggested that solves a subsection of the problems. That said, solution 4 seems the least problematic, and doesn't feel like it clashes with possible solutions to problem 2.

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