[w3c/ServiceWorker] Consider deprecating the ability for scope to match query parameters (#1469)

This has come up in regards to @wanderview 's [scope pattern matching proposal](https://github.com/wanderview/service-worker-scope-pattern-matching); in particular on [issue #4](https://github.com/wanderview/service-worker-scope-pattern-matching/issues/4). I've come to think that the current ability to match the query / search part of a URL in the service worker `scope` is totally broken; it will almost never produce the desired results and there isn't a way to make it useful. So I would like us to consider deprecating or removing it.

The [scope matching algorithm](https://www.w3.org/TR/service-workers-1/#scope-match-algorithm) performs an **exact prefix match** to determine which URLs are in scope. It is never explicitly stated in the SW spec, but this applies to the query part of the scope as well. Even when applied to the path, this is [less than desirable](https://github.com/w3c/ServiceWorker/issues/1272), but when applied to the query, it makes almost no sense. The general form of a query string in a URL is that it represents an unordered collection of key=value pairs, delimited by `&`s.

As an example, if we imagine a scope `/foo?bar=baz`, the author probably intended this to match URLs with a key "bar" having the value "baz", but there are two mistakes here:

- This won't match any URLs with "bar=baz" that isn't the first query parameter. For example, `/foo?bar=baz&boo=hoo` matches, but `/foo?boo=hoo&bar=baz` won't. So the order matters.
  - Note that query strings are often generated by placing the key/value pairs in a hash map and then serializing the hash map into the URL syntax, which means the parameters will often appear in a pseudo-random order; thus whether or not the URL matches will be flaky. (For example, Python explicitly randomizes hash table insertion order on each startup, so the order won't even be stable from one day to the next if the URLs are coming from a Python server.)
- This will match any key "bar" having a value that _starts with_ "baz" (it is a prefix match, not an exact match). `/foo?bar=bazzah` will also (probably unintentionally) match.

There is no way to fix either of these issues with the current scope syntax. For example, you could try adding a `'&'` to the end of the scope, which would limit it to an exact match, but then it would require that there be another query parameter after "bar". And there is no way to make the query parameter matching order-independent.

Supporting this in the future represents an ongoing headache:

- wanderview/service-worker-scope-pattern-matching#4 demonstrates that it would be difficult to incorporate this legacy behaviour within a "smart" pattern matching system. 
- The [Web App Manifest](https://www.w3.org/TR/appmanifest/#dfn-within-scope-manifest) scope matching algorithm is the same as service worker _except_ that it ignores the query part of the scope. I would like to unify the two algorithms into the same definition, but doing so would currently require a flag to determine whether to ignore the query part or not.

Given this, I can't imagine anybody is using this feature correctly. I would like to propose deprecation of this feature (e.g., a large red box in the spec, and recommending that user agents display a warning in the console if a '?' appears in the scope during registration), and perhaps removal if its usage is sufficiently low. https://github.com/wanderview/service-worker-scope-pattern-matching proposes a way to match query parameters correctly.

-- 
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/1469