document.cookie presents cookies as a string of name/value pairs, but no other cookie data. If there are multiple cookies of the same name we order them by best match first (most specific path/domain), but scripts can't tell if it's a good match or not. For example, is it my .example.co.uk login cookie, or an attempted .co.uk session-fixation attack (in older versions that allowed .co.uk cookies)? One way scripts could get this data in the past was by using XmlHTTPRequest and parsing cookies themselves out of .getAllResponseHeaders() data. Since fixing bug 380418 we've removed that avenue. I propose adding a read-only document.cookies array where each index returns an object containing the name, value, host, path, isSecure, expiry etc fields we support. The order of the array should match the order given in document.cookie. An associative array would be convenient (document.cookies["sessid"]) but fails in the legitimate case of duplicate cookie names. Besides, numeric indices fit the style of DOM0 frames and links arrays :-) document.cookie will remain the only way for script to add/modify/delete cookies, and setting document.cookie will require regenerating the document.cookies array. This may leave script in the page with a reference to stale cookie data but that can happen with document.cookie parsing, too.

Why do we need this? I.e. what usage pattern needs it? Document.cookie seems like it's mostly useful for client-side storing a small amount of data to be retrieved later. However these days we have various much better client side APIs. There are a few uses that I can think of beside that, but I'm not sure that they are important enough to warrant an API.

What better client side API's do we have that can also be set by the server? Cookies will always have their uses, why not make them easier to use? The main thing I want to expose is the cookie host since that's where the potential danger lies (path might be nice, too). And also an easier way of accessing them than crazy string parsing (to that end maybe I shoudn't so hastily reject document.cookies["name"] and only expose the first match if there are dupes which is more or less how sites parse cookie strings anyway). The lack of host information has been recognized as a problem for a long time, including in the Cookie: header sent to the host. The Cookie2 spec was one attempt to solve that problem. I don't think we want to turn document.cookie into a Cookie2 string, though.

https://bugzilla.mozilla.org/show_bug.cgi?id=1472046 Move all DOM bugs that haven’t been updated in more than 3 years and has no one currently assigned to P5. If you have questions, please contact :mdaly.