Repository navigation
Need to explain name matching rules for cache names #1483
Description
Steve Atkin, of the i18n WG, raise the following issue in email in Feb 2016 (see https://www.w3.org/Mail/flatten/index?subject=i18n-ISSUE-518&list=service-workers)
There was some discussion at w3c/i18n-activity#28, but that discussion needs to take place here instead.
5.5.2 has(cacheName), 5.5.3 open(cacheName), and 5.5.4 delete(cacheName)
https://slightlyoff.github.io/ServiceWorker/spec/service_worker_1/#cache-storage-has
https://slightlyoff.github.io/ServiceWorker/spec/service_worker_1/#cache-storage-open
https://slightlyoff.github.io/ServiceWorker/spec/service_worker_1/#cache-storage-delete
In each of these methods there should be an explanation of what are the name matching rules for the cacheName argument. For example, are cache names case sensitive or case insensitive? Additionally, are the names normalized to either Unicode Normal Form NFC or NFD before testing for equality?
Please see Character Model for the World Wide Web: String Matching and Searching https://www.w3.org/TR/charmod-norm/
Specifically, see section 3 https://www.w3.org/TR/charmod-norm/#identityMatching
Activity
r12a commentedon Oct 23, 2019
Lots of specs "do the right thing", but the first problem is that there are choices you need to make in defining what "the right thing" is.
Given what you are doing and the simplicity of the instructions provided, I think what you mean here goes beyond case sensitivity: the
cacheNamevalue is expected to be an identical sequence of Unicode code points to thekey. What you should do is define the term 'matches' and then use it for string comparison. For an example of this, see HTML:https://html.spec.whatwg.org/multipage/infrastructure.html#case-sensitivity-and-string-comparison
Which says:
This presumes that:
cacheNameandkeydo not include any character escapes and that they are normal DOMStrings.Our document Charmod-Norm hopefully provides explanation in case you are curious why you might want to do something different.
r12a commentedon Oct 24, 2019
The html spec says that case sensitivity is the default unless otherwise specified. Doesn't that cover us?
aphillips commentedon Nov 15, 2019
@jakearchibald I don't think it does. The problem here that Steve was noting is that you have an undefined term "matches" with no antecedent in either html or infra that I'm aware of. That leaves it open to interpretation. There be dragons.
Actually I think the better course of action is to fix html/infras definition and then use the term in place of matches (it might even be "matches") . I'm in an airplane somewhere over Iceland so can't easily look up that conversation.
If you don't want to change infra, the quick fix is to replace "matches" with "is a case sensitive match for" and refer to htmls definition.
aphillips commentedon Sep 25, 2024
This issue is still open and the issue still exists in the CRD (checked just now):
https://www.w3.org/TR/2022/CRD-service-workers-20220712/#cache-storage-has
After my plane landed in 2019 ( 😄 ) Infra did add the definition is along with a synonym "identical to". Either of these can be linked.