Serviceworker: Size constraints for cache names?

[mkruisselbrink]

Currently the spec seems to allow arbitrary (multi-MB?) long cacheNames passed to the various CacheStorage methods. Would it make sense to spec some upper limit for what browser should support regarding size of cache names (and specifying what exception to throw if that size is exceeded)?

(related to https://crbug.com/837478 where our fuzzer figured out that passing really long cache names causes chrome to kill the renderer)

[inexorabletash]

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 used for names of things so don't try and store MBs of data in them", e.g. a KeyString or NameString ?

[inexorabletash]

See also: https://github.com/inexorabletash/web-locks/issues/36