21–30 of 270 posts
The article mocks Postel's law, but if the setter of the cookie had been conservative in what they sent, there would have been no need for the article...
Cookies seem to be a big complicated mess, and meanwhile are almost impossible to change for backwards-compatibility reasons. Is this a case to create a new separate mechanism? For example a NewCookie mechanism could be specified instead, and redesigned from the ground-up to work consistently. It could have all the modern security measures built-in, a stricter specification, proper support for unicode, etc.
NewCookie is, roughly, what browser Local Storage is. At least for some use cases. Of course, it doesn't directly integrate with headers.
Cookies seem to be a big complicated mess, and meanwhile are almost impossible to change for backwards-compatibility reasons. Is this a case to create a new separate mechanism? For example a NewCookie mechanism could be specified instead, and redesigned from the ground-up to work consistently. It could have all the modern security measures built-in, a stricter specification, proper support for unicode, etc.
Earlier quoted context omitted.
> https://developer.mozilla.org/en-US/docs/Web/HTTP/Cookies#co... wait, cookie prefixes? What the heck are those? https://developer.mozilla.org/en-US/docs/Web/HTTP/Cookies#co... > For more information about cookie prefixes and the current state of browser support, see the Prefixes section of the Set-Cookie reference article. https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Se... (Cookie prefixes have been wi…
[flagged]
Cookies seem to be a big complicated mess, and meanwhile are almost impossible to change for backwards-compatibility reasons. Is this a case to create a new separate mechanism? For example a NewCookie mechanism could be specified instead, and redesigned from the ground-up to work consistently. It could have all the modern security measures built-in, a stricter specification, proper support for unicode, etc.
we're stuck with cookies because they exist.
Cookies are a bit of a mess, but if you're going to use them, you can follow the standard and all will be well. Not so much a minefield, but a hammer; you just need to take some care not to hit yourself on the thumb.
I guess the confusion here is that the browser is taking on the role of the server in setting the cookie value. In doing so it should follow the same rules any server should in setting a cookie value, which don't generally allow for raw JSON (no double-quote! no comma!).
Either use a decent higher-level API for something like this (which will take care of any necessary encoding/escaping), or learn exactly what low-level encoding/escaping is needed. Pretty much the same thing you face in nearly anything to do with information communication.
Cookies seem to be a big complicated mess, and meanwhile are almost impossible to change for backwards-compatibility reasons. Is this a case to create a new separate mechanism? For example a NewCookie mechanism could be specified instead, and redesigned from the ground-up to work consistently. It could have all the modern security measures built-in, a stricter specification, proper support for unicode, etc.
Needs a better name than NewCookie though. Suggestions include SuperCookie, UltraCookie or BetterCookie Or to be slightly more serious avoid calling it a cookie and call it something else. Too much baggage surrounding the word cookie.
You graduate from consuming cookies to eating...
The article mocks Postel's law, but if the setter of the cookie had been conservative in what they sent, there would have been no need for the article...
As they should. Postel's Law was a terrible idea and has created minefields all over the place.
Sometimes, those mines aren't just bugs, but create gaping security holes.
If your client is sending data that doesn't conform to spec, you have a bug, and you need to fix it. It should never be up to the server to figure out what you meant and accept it.
Cookies seem to be a big complicated mess, and meanwhile are almost impossible to change for backwards-compatibility reasons. Is this a case to create a new separate mechanism? For example a NewCookie mechanism could be specified instead, and redesigned from the ground-up to work consistently. It could have all the modern security measures built-in, a stricter specification, proper support for unicode, etc.
That feels like that XKCD comic about now there being 15 standards.
Firefox accepts five characters which RFC recommends that servers not send: 0x09 (horizontal tab) 0x20 (spaces) 0x22 (double quotes) 0x2C (commas) 0x5C (backslashes) I agree with at least some of these. Cookies without commas? Quotes?
Quotes in the value when quotes delimit the value? Yeah that seems dangerous to me.