[whatwg] HTML Cookie API

[Adam Barth]

On Wed, Feb 24, 2010 at 4:03 PM, Garrett Smith <dhtmlkitchen at gmail.com> wrote:
> On Tue, Feb 23, 2010 at 8:56 PM, Adam Barth <w3c at adambarth.com> wrote:
>> The document.cookie API is kind of terrible.  Web developers shouldn't
>> have to parse a cookie-string or prepare a properly formated
>> set-cookie-string.  Here's a proposal for an HTML cookie API that
>> isn't as terrible:
>>
>> https://docs.google.com/Doc?docid=0AZpchfQ5mBrEZGQ0cDh3YzRfMTRmdHFma21kMg&hl=en
>>
>> I'd like to propose we include this API in a future version of HTML.
>> As always, feedback welcome.
>>
> | Because HttpOnly cookies are inaccessible to script, the |httpOnly|
> | attribute will usually be false.
>
> Usually? When ever would HttpOnly be true?

For example, if the HTML document is running with higher privileges
because its effective security origin isn't a (scheme, host, port)
tuple.  This can occur, e.g., in Firefox when running with "chrome"
privileges.

> Instead of "array like", I would like to rather have a NamedCookieMap,
> which is sort of like a NamedNodeMap that the cookies can be retrieved
> by an item or namedItem.

That API design assumes that there's only one cookie with a given name
in each cookie-string.  Unfortunately, that is not a valid assumption.

> Where is the argument for making the API async?

Please see the discussion earlier in this thread.

> Cookies have been synchronous for longer than I have been writing
> javascript and to my knowledge, nobody has ever complained of that
> being a problem.

In fact, I've heard a great many complaints about this recently
(particularly from Darin Fisher), which is part of what prompted me to
make this proposal.

> Asynchronous cookies that would mean that cookie setting tests would be harder.

No one is suggesting removing the current document.cookie API.  You
can continue to use whatever cookie setting test you're current using.

Adam