Subject: [http-state] HTML5 - cookie specification interaction

From: "Anne van Kesteren" <[email-masked]>
Date: Sat, 10 Jul 2010 13:48:16 +0200

HTML5 tries to pass the cookie specification a string passed to  
document.cookie. It seems however that the cookie specification expects  
cookie names and values. Am I overlooking something?

-- 
Anne van Kesteren
http://annevankesteren.nl/

---

From: Adam Barth <[email-masked]>
Date: Sat, 10 Jul 2010 11:30:15 -0700

> cookie names and values. Am I overlooking something?

The cookie specification defines entry points at two layers for other
specifications.  You can either interact with cookies using unparsed
strings or using parsed name/value pairs.  When setting
document.cookie, HTML5 will probably want to tell the user agent
*receive a set-cookie-string* for the document's URL, which invokes
the parser in Section 5.2:

http://tools.ietf.org/html/draft-ietf-httpstate-cookie-09#section-5.2

If an API deals with parsed cookie data, you can interface with the
storage model directly (bypassing the parser) by telling the user
agent to *receive a cookie* with a given name/value and attribute
list:

http://tools.ietf.org/html/draft-ietf-httpstate-cookie-09#section-5.3

For reading document.cookie, HTML5 will probably want to ask the user
agent to generate a *cookie-string* for the document's URL.

http://tools.ietf.org/html/draft-ietf-httpstate-cookie-09#section-5.4

These entry points used to be delimited by *s, as is customary in
higher level specifications, but the working group asked me to remove
the demarcations.  Unless something drastically unexpected happens,
you can consider those entry points stable.

Adam

---

From: "Anne van Kesteren" <[email-masked]>
Date: Tue, 13 Jul 2010 11:16:26 +0200

> http://tools.ietf.org/html/draft-ietf-httpstate-cookie-09#section-5.2

Ah okay, thanks, should this not mention non-HTTP API as well then? I  
searched for non-HTTP API as that is what HTML5 currently says and only  
found section 5.3 and some unrelated stuff.

> you can consider those entry points stable.

Why does this section (5.4) talk about an "HTTP" API rather than a  
non-HTTP API?

---

From: Adam Barth <[email-masked]>
Date: Tue, 13 Jul 2010 08:33:27 -0700

> found section 5.3 and some unrelated stuff.

Yep.

> Why does this section (5.4) talk about an "HTTP" API rather than a non-HTTP
> API?

No particular reason.  I'll flip around some of the negatives so we
can say non-HTTP API here as well.

Adam