51–60 of 270 posts
IT IS a mess, but I never saw json inside a cookie. For json I use local storage or indexeddb.
In both cases (cookie vs localStorage) you're really just storing your data as a string value, not truly a JSON object, so whether you use a cookie or localStorage is more dependent on the use case. If you only ever need the stored data on the client, localStorage is your pick. If you need to pass it back to the server with each request, cookies.
[comment intended for a different post, but too old to delete]
None of this explicitly has anything specifically to do with HTML.
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.
i think the main problem there is that cookies are so intractibly tied up with tracking, any attempt to create better cookies now will get shut down by privacy advocates who simply don't want the whole concept to exist. we're stuck with cookies because they exist.
Being anti-ads is a valid opinion. It has less intellectual cover than pro “privacy” though.
Earlier quoted context omitted.
Per the section 4.1.1 rules quoted in the article, cookie values can be optionally quoted: > cookie-value = cookie-octet / ( DQUOTE cookie-octet DQUOTE )
That is true, but in that case they are part of the value itself, they're not doing anything special: > Per the grammar above, the cookie-value MAY be wrapped in DQUOTE characters. Note that in this case, the initial and trailing DQUOTE characters are not stripped. They are part of the cookie-value, and will be included in Cookie header fields sent to the server.
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.
It's funny that you mention NewCookie, there is actually a deprecated Set-Cookie2 header already: https://stackoverflow.com/q/9462180/3474615
IT IS a mess, but I never saw json inside a cookie. For json I use local storage or indexeddb.
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?
Earlier quoted context omitted.
In both cases (cookie vs localStorage) you're really just storing your data as a string value, not truly a JSON object, so whether you use a cookie or localStorage is more dependent on the use case. If you only ever need the stored data on the client, localStorage is your pick. If you need to pass it back to the server with each request, cookies.
JSON is explicitly a string serialization format.