Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

what is the key for a keyless value? #22

Open
patrickkettner opened this issue Mar 11, 2017 · 9 comments
Open

what is the key for a keyless value? #22

patrickkettner opened this issue Mar 11, 2017 · 9 comments

Comments

@patrickkettner
Copy link
Owner

document.cookie="foo" creates a keyless cookie. We need to define what happens when that value is put into the object form. Options I can think of would be...

  { '': 'foo' }
  { undefined: 'foo' }
  { null: 'foo' }

Feel like undefined is the correct path here, but would like to collect feedback before defining the behavior

@bsittler
Copy link

FYI, there is not complete cross-browser consensus on this - see https://inikulin.github.io/cookie-compat/ for the shocking results of @inikulin 's research into this (and many other) aspects of cookie interoperability

@patrickkettner
Copy link
Owner Author

thanks for the ref! I actualyl did check it out before the initial explainer. The question here was when given the object representation of a cookie (a Cookie, in the context of this spec), when someone set a cookie like so

`document.cookie="=foo", (which is valid...for some reason), should cookie.name be a string or not. The case against obviously being that strings are truthy, and given that a developer used that cookie for some reason, they may be keying off of that value being not truthy.

@bsittler
Copy link

That makes sense. If it were up to me I would use an empty string to avoid surprises, but none of the options here is particularly good.

@patrickkettner
Copy link
Owner Author

what surprises do you imagine encountering? Really interested in contrarian feedback, because literally ever web developer I have asked about this situation has heavily preferred undefined (and I want to make sure I am not in some kind of echo chamber).

@bsittler
Copy link

bsittler commented Mar 17, 2017

I believe existing cookie libraries - both server-side and client-side - that allow empty-name cookies of the form Set-Cookie: =value[; flags...] at all (as opposed to ignoring/discarding them) mostly treat the name as "" (empty string). I think that for this API to do something different would be surprising. Perhaps @FagnerMartinsBrack has more experience and insight here

@FagnerMartinsBrack
Copy link

FagnerMartinsBrack commented Mar 17, 2017

I always refer to RFC 6265. It says the cookie-value can contain anything in a token which is:

OCTET = <any 8-bit sequence of data>
CHAR = <any US-ASCII character (octets 0 - 127)>
UPALPHA = <any US-ASCII uppercase letter "A".."Z">
LOALPHA = <any US-ASCII lowercase letter "a".."z">
ALPHA = UPALPHA | LOALPHA
DIGIT = <any US-ASCII digit "0".."9">
CTL = <any US-ASCII control character
(octets 0 - 31) and DEL (127)>
CR = <US-ASCII CR, carriage return (13)>
LF = <US-ASCII LF, linefeed (10)>
SP = <US-ASCII SP, space (32)>
HT = <US-ASCII HT, horizontal-tab (9)>
<"> = <US-ASCII double-quote mark (34)>

It says it can contain control characters. However, it doesn't say it's optional or that it can be empty. Therefore, I would argue one should not let the user create a cookie with an empty cookie-name because that's not allowed, or if let them do so, then it's an undefined behavior.

js-cookie have never received any report of someone setting the key as empty and having an astonishing result or complaining about interoperability. By looking at the code, it looks like js-cookie will not validate and will just set document.cookie = '=value' if an empty key is provided. The behavior there is undefined, until someone complains about it.

I don't know if there are additional implications on having an empty string. Maybe asking for the ones who wrote the spec at the time?

@patrickkettner
Copy link
Owner Author

Therefore, I would argue one should not let the user create a cookie with an empty cookie-name because that's not allowed, or if let them do so, then it's an undefined behavior.

You can today, and therefore I can't stop someone from settings those values.

document.cookie="=foo" and document.cookie="bar" both set cookies in every browser I can get my hands on, and in a consistent way. I totally understand that it is an edge case, but it is a case that the IDL has to be able to represent, lest we have incompatible implementations for a problem we could see beforehand.

@bsittler
Copy link

Does "every browser I can get my hands on" exclude Safari?

I believe that in Safari "=foo" is ignored and "bar" is equivalent to "bar=", whereas in Firefox, IE, Edge and Chrome "=foo" is setting the cookie whose name is "" and "bar" is too, since it's equivalent to "=bar".

@patrickkettner
Copy link
Owner Author

you are correct

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants