On Wed, Feb 24, 2010 at 4:03 PM, Garrett Smith <[email protected]> wrote: > On Tue, Feb 23, 2010 at 8:56 PM, Adam Barth <[email protected]> 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
