W3C home > Mailing lists > Public > whatwg@whatwg.org > February 2010

[whatwg] HTML Cookie API

From: David Flanagan <david@davidflanagan.com>
Date: Wed, 24 Feb 2010 11:52:21 -0800
Message-ID: <4B858375.90604@davidflanagan.com>
Boris Zbarsky wrote:
> On 2/24/10 1:04 PM, David Flanagan wrote:
>> If I've been following the thread correctly, the justification for an
>> asynchronous API was that localStorage is a mess, or something like
>> that. I'm not aware of what the issues are with localStorage
> In brief, the fact that if you have multiple threads or processes 
> rendering web pages from the same site, then they can race each other.
>> could you justify an asynchronous cookie API more explicitly? This 
>> isn't a
>> blocking I/O issue, is it? Surely browsers will have the relevant
>> cookies already cached in memory, won't they?
> Yes, but cookies are not immutable.
>> In simple use cases, a developer just wants the cookie value
> Only once?  With a sync API this code:
>   if (document.cookie == document.cookie) {
>     alert("pass");
>   } else {
>     alert("fail");
>   }

> will sometimes alert "fail" depending on what other web pages are 
> loading at the same time and what their HTTP headers look like and what 
> their scripts are doing.
> -Boris

[Changing the subject line back]

Doesn't the HTML5 storage mutex fix this?

With the storage mutex mechanism it is possible to create a safe (no way 
to observe volatility) synchronous version of getCookies(), isn't it? 
The downside is that getCookies() might have to block while waiting for 
the mutex. But is that really a reason not to allow synchronous 
(blocking) access to cookies?  Given that the storage mutex is already 
in the spec, doesn't it make sense to define a better synchronous API in 
addition to the new asynchronous API?

Received on Wednesday, 24 February 2010 11:52:21 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:21 UTC