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

> The scope is a prefix, so it seems pretty obvious that order of things in the query string matters.

Yes, but I don't think it's particularly obvious that the scope is a prefix match (if you just learn by example, as opposed to reading the spec, I think it's fairly unintuitive both a) that the path is prefix-based as opposed to hierarchical; see #1272, and b) that the query is prefix-based as opposed to matching individual key=value pairs).

Up until now, I hadn't really thought about the query part, and I was surprised to realise that it behaves this way (even though I had previously read the spec that it was a prefix match, I didn't put 2 and 2 together to realise that this imposes a strict ordering on the query part of a URL). As I said above, I don't think there's really any way to use this feature correctly.

> I don't think we can just add pattern matching to regular scope strings (and other places we use URLs). `*` crops up in most patterns, and it's also valid in a URL.

I think @wanderview is doing a good job figuring out how to add more flexible scope matching (on [wanderview/service-worker-scope-pattern-matching](https://github.com/wanderview/service-worker-scope-pattern-matching/blob/master/explainer.md)) so I'm not proposing any new syntax here. I just think it would be good to remove this mis-feature.

> If someone deliberately puts `?foo` in a scope string, it seems weird to just ignore it. Shouldn't it do something, or throw?

It should probably log a warning. Even if we don't ignore it, I think we should still advise implementations to log a warning because of the surprising behaviour.

Note that the [Manifest spec](https://www.w3.org/TR/appmanifest/#dfn-within-scope) does just ignore the query.

-- 
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#issuecomment-531615790

Received on Monday, 16 September 2019 00:59:47 UTC