-
Notifications
You must be signed in to change notification settings - Fork 3
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
Comments
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 |
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. |
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. |
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 |
I believe existing cookie libraries - both server-side and client-side - that allow empty-name cookies of the form |
I always refer to RFC 6265. It says the
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 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 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? |
You can today, and therefore I can't stop someone from settings those values.
|
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". |
you are correct |
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...
Feel like
undefined
is the correct path here, but would like to collect feedback before defining the behaviorThe text was updated successfully, but these errors were encountered: