Did anyone else notice that the HTTP protocol embeds within it ten-thousand different protocols? Browsers and web servers both "add-on" a ton of functionality, which all have specifications and de-facto specifications, and all of it is delivered through the umbrella of basically one generic "HTTP" protocol. You can't have the client specify what version of these ten-thousand non-specifications it is compatible with, and the server can't either. We can't upgrade the "specs" because none of the rest of the clients will understand, and there won't be backwards-compatibility. So we just have this morass of random shit that nobody can agree on and can't fix. And there is no planned obsolescence, so we have to carry forward whatever bad decisions we made in the past.
Handling cookies is a minefield
61–70 of 270 posts
Re: Handling cookies is a minefield
#62Earlier quoted context omitted.
NewCookie is, roughly, what browser Local Storage is. At least for some use cases. Of course, it doesn't directly integrate with headers.
I think one important use case we have for cookies is "Secure; HttpOnly" cookies. Making a token totally inaccessible from JS, but still letting the client handle the session is a use case that localStorage can't help with. (Even if there's a lot of JWTs in localStorage out there.)
However, potentially a localStorage (and sessionStorage!) compatible cookie-replacement api might allow for annotating keys with secure and/or HttpOnly bits? Keeping cookies and localStorage in sync is a hassle anyhow when necessary, so having the apis align a little better would be nice. Not to mention that that would have the advantage of partially heading off an inevitable criticism - that users don't want yet another tracking mechanism. After all, we already have localStorage and sessionStorage, and they're server-readable too now, just indirectly.
On the other hand; the size constraints on storage will be less severe than those on tags in each http request, so perhaps this is being overly clever with risks of accidentally huge payloads suddenly being sent along with each request.
Re: Handling cookies is a minefield
#63> Apple Support
Are we sure the website wasn't just broken normally? I kid, a bit, but good lord does Apple _suck_ at websites. Apple Developer and, more often, App Store Connect is broken for no good reason with zero or a confusing error message.
Note: I'm typing this on a M3 Max MBP (via a Magic Keyboard and Magic Mouse) with an iPhone 16 Pro and iPad Mini (N-1 version) on the desk next to me with an Apple Watch Series 10 on my wrist and AirPods Pro in my pocket. I'm a huge Apple fanboy, but their websites are hot garbage.
Re: Handling cookies is a minefield
#64> minefield 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 cook…
I don’t understand how that’s not a minefield, it’s easy to go astray?
Probably just semantics.
Re: Handling cookies is a minefield
#65Re: Handling cookies is a minefield
#66Earlier 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.
[deleted]
Re: Handling cookies is a minefield
#67IT IS a mess, but I never saw json inside a cookie. For json I use local storage or indexeddb.
You're really going to hate it when you learn about JSON Web Tokens, which exist exactly to hack past this sort of problem.
Re: Handling cookies is a minefield
#68The 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...
> The article mocks Postel's law 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.
And yet the html5 syntax variation survived (with all it's weird now-codified quirks), and the simpler, stricter xhtml died out. I'm not disagreeing with out; it's just that being flexible, even if it's bad for the ecosystem is good for surviving in the ecosystem.
Re: Handling cookies is a minefield
#69IT 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.
Combine local storage with service worker, so you pass the data to the server if needed. Completely without setting cookies.
Re: Handling cookies is a minefield
#70> Handling cookies is a minefield
I know! You gotta let them cool down first. Learned this the hard way.