Re: [http-state] non-ASCII cookie values (was Re: Closing Ticket 3: Public Suffixes)

[Dan Winship <[e-mail]>]

On 02/02/2010 07:27 PM, Maciej Stachowiak wrote:
> HTML5 does not spec this detail and apparently expects the cookie
> spec to expose a string interface, not an octet-sequence
> interface:
> http://dev.w3.org/html5/spec/Overview.html#dom-document-cookie

Slight tangent...

One of the major reasons cookies are such a disaster is that web site
frameworks and document.cookie both expose cookies to web site authors
as just strings, and expect the web site authors to get all the nasty
syntax details correct. Which they of course don't.

Although in the short term we need to nail down exactly how
document.cookie works for backward-compatibility purposes, in the long
run, we might be able to make the world a better place if we helped
design a fabulous new higher-level cookie API for HTML5, where the
browser would handle the tricky syntax bits, and would just throw an
exception if the page tried to use an illegal cookie name, etc. This new
API could even fix some issues that we aren't currently able to fix in
the spec, eg, by setting the "Secure" flag on the cookie by default if
the page had been loaded over https, etc.

(And likewise, the spec could recommend that web site
frameworks/libraries SHOULD provide similar idiot-proof high-level
cookie APIs, rather than expecting authors to generate valid Set-Cookie
headers by themselves.)

-- Dan