Support no-value cookies?

[domenic]

Apparently document.cookie supports cookies with no value via document.cookie = "foo". This is distinct on the wire (i.e. in the resulting HTTP headers) from cookies with value empty string (document.cookie = "foo=").

Is support for this needed, so that this API encompasses the entire cookie data model, or can we be stricter?

Related: whatwg/html#804

[bsittler]

One option (though it complicates the API slightly) would be to default to stricter https://tools.ietf.org/html/rfc6265#section-4.1 rules by default, but have a flag to permit relaxation to https://tools.ietf.org/html/rfc6265#section-5.2 rules when absolutely necessary for interoperability, e.g. ... {[' permissive ']: true} - similarly the read APIs could have an option to relax parsing ... {[' permissive ']: true}

[bsittler]

Another alternative to all this would be a radically simpler API - navigator.getCookies().then(jar => {...} ) which is merely an async read of document.cookie, and navigator.setCookie(string).then(() => {...}) which is merely an async write of document.cookie

@cramforce what do you think? how much hand-holding, parsing assistance, etc. is actually useful?

[bsittler]

(that's more or less the original proposal by @slightlyoff from w3c/ServiceWorker#707 (comment) )

[domenic]

Forked that radically simpler API discussion to #8

[bsittler]

See also this discussion of nameless and/or valueless cookies:

https://www.ietf.org/mail-archive/web/http-state/current/msg00320.html

The cookie RFC says valueless set-cookie attempts are ignored, but in fact browsers do not seem to ignore them.

[bsittler]

@abarth - do you have any idea whether valueless cookies are used in the real world?

[abarth]

@bsittler If they exist in the wild, they're exceedingly rare. They certainly have cropped up at least once in the past. If you're defining a new API for cookies, I wouldn't worry about them. It's debatable whether folks implementing existing APIs (i.e., document.cookie and Set-Cookie) ought to worry about them.

[bsittler]

@inikulin did some excellent work on ferreting out implementation-vs.-spec and implementation-vs.-implementation behavior mismatches as part of whatwg/html#804 - one of the clearest signals I perceive in those results so far is that empty-name and empty-value cookies are not handled at all consistently across browsers. Omitting support for setting them is likely the right thing to do. For reads it's not clear to me what is best; we could omit them, we could treat them as anonymous cookies with values, or we could treat them as named cookies with no values. For the degenerate case of anonymous, valueless cookies I think the near-consensus among the implementations is to simply ignore them

Edit: deep link to results page: http://inikulin.github.io/cookie-compat/

Edit 2: A few more observations:

• path handling is odd and inconsistent when the supposed "path" involves a query string
• multiple occurrences of the same attribute lead to inconsistent behavior
• max-age support is inconsistent
• support for characters outside the ASCII range is inconsistent (!)
• support for, and the meaning of, double-quote is inconsistent

[bsittler]

The new explainer outlines a more restrictive API which disallows both reading and writing no-value cookies. Some of the other inconsistencies mentioned here are implicitly addressed by that outline (character set: always UTF-8 for reading and writing/USVString from script perspective, max-age: not present in the proposed API for writing cookies, multiple occurrence of the same attribute: not possible in the proposed API for writing cookies) but the rest still need to be addressed.

[bsittler]

Fixed explainer link

[domenic]

Please stop spamming my inbox with notifications that you edited a post :(. We can all just see the new post...

[bsittler]

Will do, didn't realize!

On Jul 27, 2016 10:39, "Domenic Denicola" notifications@github.com wrote:

Please stop spamming my inbox with notifications that you edited a post
:(. We can all just see the new post...

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#1 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAD3R8Yq9S6wCtz36W4tHP4DpmluD9b2ks5qZ5e2gaJpZM4Hpuvz
.

[bsittler]

Further reading of the cookie compatibility results from https://inikulin.github.io/cookie-compat/ makes it fairly obvious that there is de-facto standard behavior for Set-Cookie with no '=' across all browsers tested except Safari. Specifically, it is treated identically to the same Set-Cookie prefixed with '=', and updates the cookie with the empty-string name. I will go ahead and follow the majority behavior here in the polyfill and assume the spec will probably be changed to match that.