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

> I agree the real solution is to do maps.google.com, or as a workaround can they claim all of "maps*" (i.e., move mapsearch somewhere else?)

There is no "mapsearch". This is just a hypothetical example of why the current options are too limited.

Note that just because this is hypothetical does not mean it isn't a problem *right now*. google.com/maps is real. While google.com/mapsearch is not real, the possibility of google.com/maps* in the future makes it dangerous for them to define a service worker with "google.com/maps" as the scope. But they can't define "google.com/maps/" as the scope, because that would exclude their canonical URL!

This dilemma affects 100% of applications whose scope is not "/". You could argue that they should use "maps.google.com" instead; I tend to agree, but then why does "scope" exist as a concept (why not just automatically scope SWs to the origin)?

> I think we should take care to have a solution that meets the big use cases instead of a quick fix now.

I agree that it might be useful to have more expressive scoping. But the issue I'm talking about here means that "scope" as a concept is fundamentally broken. It just isn't broken *too badly* which is why not many people are complaining; 1. because most scopes are probably "/", and 2. because everybody else is probably defining over-broad scopes by accident, or excluding their non-slashed URL by accident, which means subtle breakage, not catastrophic. I still think this should be fixed as a priority.

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