[whatwg] Storage mutex and cookies can lead to browser deadlock

[Benjamin Smedberg]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 9/1/09 7:31 PM, Jeremy Orlow wrote:

> Does the silence mean that no one has any intention of implementing
> this?  If so, maybe we should resign ourselves to a break in the single
> threaded illusion for cookies.  This doesn't seem too outlandish
> considering that web servers working with cookies will never have such a
> guarantee and given that we have no evidence of widespread breakage with
> IE 8 and Chrome.

We (Firefox) just started looking at this seriously: the performance
implications of the current global mutex are pretty unpleasant. Reading the
spec, I didn't realize that the mutex was global instead of per-domain; I
only figured that out reading the discussions here.

The major race condition appears to be code on the web that gets
document.cookie, parses and modifies the string it to add or remove a
particular cookie, and sets document.cookie again. This pattern could race
against HTTP requests which also set cookies.

Chris Jones proposed that we behave in a script-consistent manner without
actually implementing any sort of mutex:

* When a script gets document.cookie, "check out" a consistent view of the
cookie data. While the script runs to completion, its view of
document.cookie does not change.
* When the script sets document.cookie, it calculates the delta with the
original data and "commit" the changes.
* The consistent view is maintained until the script runs to completion (or
enters a nested event loop, all the locations which are currently marked as
releasing the storage Mutex in the current spec)
* HTTP Set-Cookie headers stomp on prior data at any time, but don't
interfere with the consistent script view above.

It would be nice to provide a web API to perform the operation of setting a
cookie atomically, just as the Set-Cookie HTTP header does. That is:
document.setCookie('foo=bar; domain=subd.example.com')

It's not clear whether/how this same algorithm could be applied to
localStorage, since the amount of data required to create a consistent state
is potentially much larger. Is there an inherently racy API in .localStorage
which we need to protect with complicated mutex/transactional schemes?

In addition, we had concerns about how the web-browser UI itself might
interact with the global mutex. I don't think we'd want browser UI such as
the cookie manager or "Clear Private Data" to wait for content script to run
to completion. Can we make it explicit in the spec that the UA may remove
cookies or localStorage data at any time without owning the storage mutex?

- --BDS
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iD8DBQFKoCYdSSwGp5sTYNkRAi9yAKCq3GesFDNDrn134621Hm8XJaMB8ACgmIhC
3VcXlEKmSb2l83ekH0j3Hgg=
=FldI
-----END PGP SIGNATURE-----