Re: [w3c/ServiceWorker] Size constraints for cache names? (#1310)

This problem occurs in many places in the web platform, where specs don't impose limits on strings or similar structures. Storage-associated places that come to mind...

* localStorage key/value lengths
* Indexed DB database/store/index names lengths
* Indexed DB key/keypath lengths
* Indexed DB key depth (for array keys)
* BackgroundSync's tag length

But also maybe everything in DOM, e.g. IDs on elements?

In the past we've handwavily said the UA can impose arbitrary limits... not sure that's written down anywhere for most of these cases/specs. IMHO, we should probably stop pretending we don't need to worry about this in specs.

If we impose a limit in the spec, we need to be explicit about whether it applies to the length of the string in JavaScript 16-bit code units, or as a length in bytes after transcoding to UTF-8, and have tests.

re: exception type: TypeError makes sense to me. So sprinkle this everywhere:

> N. If the length of _cacheName_ in code units is greater than 1000, return a promise rejected with TypeError

Potentially crazy thought: since this problem occurs throughout the platform, what about defining a new string type in WebIDL for "strings uses for names of things so don't try and store MBs of data in them", e.g. a KeyString or NameString ?


-- 
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/1310#issuecomment-385043727