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

The current behavior of ServiceWorker scope matching being a simple string prefix is a bigger problem than just the maps-trailing-slash example.  Here's another non-hypothetical example: I want to install a simple ServiceWorker on the Google homepage - www.google.com - in order to speed it up and make some functionality available offline.  However, there are a ton of other properties hosted on www.google.com that I don't want this ServiceWorker to be activated for - today any SW that handles requests to www.google.com (or www.google.com/ with the slash) must also intercept every request to www.google.com/maps, www.google.com/flights, www.google.com/search, www.google.com/preferences, and countless more.  It's very much not a feasible solution to contact all the unknown number of people who own some random path off of www.google.com and ask them to install an empty ServiceWorker so we don't add latency and potential bugs to their serving path.

@slightlyoff 's proposal around allowing a SW to specify multiple paths and limiting some to the exact specified path rather than treating it as a prefix solves this problem nicely, as well as the maps-trailing-slash case, as well as some others (such as wanting to register for example.com/myapp and example.com/settings but not example.com/betatestapp), in a relatively straightforward way.

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