- From: Matt Giuca <notifications@github.com>
- Date: Sun, 15 Sep 2019 17:59:25 -0700
- To: w3c/ServiceWorker <ServiceWorker@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <w3c/ServiceWorker/issues/1469/531615790@github.com>
> 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