search

w3c / ServiceWorker

Service Workers
https://w3c.github.io/ServiceWorker/
Other
3.63k stars 313 forks source link

Need to explain name matching rules for cache names #1483

Open r12a opened 5 years ago

r12a commented 5 years ago

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 https://github.com/w3c/i18n-activity/issues/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

r12a commented 5 years ago

The following comment was made by @aphillips in response to the following question by @jakearchibald: "Is there an example of a spec that does the right thing here. The intent is for the match to be case sensitive."

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 cacheName value is expected to be an identical sequence of Unicode code points to the key. 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:

Comparing two strings in a case-sensitive manner means comparing them exactly, code point for code point. Except where otherwise stated, string comparisons must be performed in a case-sensitive manner.

This presumes that:

Our document Charmod-Norm hopefully provides explanation in case you are curious why you might want to do something different.

r12a commented 5 years ago

Follow on question from @jakearchibald:

The html spec says that case sensitivity is the default unless otherwise specified. Doesn't that cover us?

aphillips commented 4 years ago

@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 commented 1 month ago

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.