[whatwg] HTML Cookie API

[Jeremy Orlow]

On Wed, Feb 24, 2010 at 8:52 PM, David Flanagan <david at davidflanagan.com>wrote:

> 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?
>

Please read my email from 30 minutes ago.


> With the storage mutex mechanism it is possible to create a safe (no way to
> observe volatility) synchronous version of getCookies(), isn't it?


Sure.


> The downside is that getCookies() might have to block while waiting for the
> mutex.


Exactly.


> But is that really a reason not to allow synchronous (blocking) access to
> cookies?


YES!


> Given that the storage mutex is already in the spec,


It's in the spec, but no one has implemented it or signaled any intention to
do so.  We at Google have gone so far as to say that we will not implement
it.  So, even though it's there, I'm not sure how much it means at this
point.


> doesn't it make sense to define a better synchronous API in addition to the
> new asynchronous API?


Please see all the LocalStorage discussions and then see if you still think
it's possible to do such a thing.

J
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100224/6d8123e3/attachment-0002.htm>