[SessionStorage] Invalid UTF16 key handling causes entries to change after loading from disk. |
|||
Issue descriptionSession storage keys are always converted to UTF8 before saving to disk. When there is an invalid utf16 string (with unpaired surrogates), this is replaced with 0xfffd. However, the in-memory session storage cache keeps the original utf16 data as a key. So data will seem correct here. However, if session storage is reloaded from disk, then the key loaded into memory will be the one with 0xfffd's, and it will no longer work. Todo - add metrics to track how many keys have FFFD surrogates. Possibly fix by causing session storage to throw an exception on invalid utf16 keys.
,
Sep 20
Rather than throwing, we could change the key from DOMString to USVString which will do the surrogate replacement. But that's a web API change. There should be a code path somewhere for 'WTF-8' conversion which is UTF-8 but handles unpaired surrogates.
,
Sep 20
(note that it won't be called WTF-8. That's a totally unofficial name invented at https://simonsapin.github.io/wtf-8/ to describe this stuff)
,
Oct 2
... and it doesn't look like this is exposed in base/strings/ which is where I think we got stuck on similar issues in the past.
,
Oct 2
,
Oct 2
See issue 432746 and https://codereview.chromium.org/1768063002/ and https://codereview.chromium.org/1751833002/ for a related issue/attempted fixes.
,
Oct 3
Solving this will let us change the session storage backend more easily to be UTF8. Marking as available P3. |
|||
►
Sign in to add a comment |
|||
Comment 1 by dmu...@chromium.org
, Aug 10