Consider deprecating the ability for scope to match query parameters

This has come up in regards to @wanderview 's scope pattern matching proposal; in particular on issue #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 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, 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 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.

Start with the Service Worker scope matching algorithm linked in the issue, then read the related scope pattern matching proposal and issue #4. Compare its query handling with the Web App Manifest algorithm and determine whether the proposed deprecation or removal can be specified consistently; completion would require an agreed standards change.