Re Safari’s networking code being closed source, a good substitute might be the Swift port of Foundation. You can see checks for control and delete characters here: https://github.com/swiftlang/swift-corelibs-foundation/blob/...
Handling cookies is a minefield
121–130 of 270 posts
Re: Handling cookies is a minefield
#122Earlier quoted context omitted.
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.
His Majesty's English might suggest "biscuit".
What do the British call biscuits?
https://chefjar.com/wp-content/uploads/2021/05/popeyes-biscu...
Re: Handling cookies is a minefield
#123Cookies are filled with weird gotchas and uncomfortable behavior that works 99.95% of the time. My favorite cookie minefield is cookie shadowing - if you set cookies with the same name but different key properties (domain, path, etc.) you can get multiple near-identical cookies set at once - with no ability for the backend or JS to tell which is which. Try going to https://example.com/somepath and entering the follow…
I wonder if this explains a lot of the unusual behaviour that happens when you use multiple accounts on a website in the same browser.
Re: Handling cookies is a minefield
#124Earlier quoted context omitted.
Not really. A lot of essential third party Rust crates and projects have "weird" names, eg. "nom", "tokio", etc. You can see that from the list of most downloaded crates [1]. This one just happens to have been owned and maintained by core Rust folks and used in a lot of larger libraries. This is more the exception than the rule. It's a given that you should do due diligence on crates and not just use the first name t…
> Rust crates need namespacing to avoid this and similar problems going forward. It hasn't been implemented despite crowd demanding it on HN for years because it won't solve the problem (namespace squatting is going to replace name squatting and tada! you're back to square one with an extra step).
There are problems it does solve though. It’s incomprehensible that we get so many new package managers that fail to learn from the bajillion that came before.
Re: Handling cookies is a minefield
#125Earlier quoted context omitted.
Yeah, isn’t that how you represent a list of values? (Or maybe better to say a collection, not sure if ordering is preserved)
But if the attributes are exactly the same then the cookies replace each other. So this isn't a general mechanism for representing a list. Not to mention that the way to delete a cookie is sending a replacement cookie that expires in the past. How are you supposed to delete the right cookie here?
[dead]
Re: Handling cookies is a minefield
#126> 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 Se…
But why wouldn't web pages written in ObjC be just awesome and easy to manage?! https://en.wikipedia.org/wiki/WebObjects I can still remember when they'd purposefully take down their store page for some godforsaken reason. The mind reels
They still do take the store page offline in the leading hours and during a keynote.
Re: Handling cookies is a minefield
#127I got the impression that almost as soon as they were introduced people thought the only sensible use of cookies is to set an opaque token so the server can recognize the client when it sees it again, and store everything else server side.
I don;t understand why it's a problem that the client (in principle) can handle values that the server will never send. Just don't send them, and you don;t have to worry about perplexing riddles like "but what would happen if I did?"
Re: Handling cookies is a minefield
#128Earlier quoted context omitted.
Just want to point out that location names are used for codenames because they cannot be trademarked Big tech uses them instead of wasting legal time and money having to clear a new name that's temporary or non-public. Changing the name to Tokio removes this benefit and still leaves it disconnected from its purpose.
The name of the city is 東京 -- anything in Latin characters is a rough transliteration. Tokio was the common spelling in European texts until some time last century, and is still used regularly in continental Europe. see also, e.g. Tokio Hotel
Tokio is a different (masculine) name in Japanese, pronounced quite differently. /tokʲio/ vs. /to̞ːkʲo̞ː/.
Re: Handling cookies is a minefield
#129The 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 problem with Postel's law is exactly that the sender is never conservative, and will tend to use any detail that most receivers accept.
So the problem with Postel's law is that people don't follow Postel's law?
Re: Handling cookies is a minefield
#130Cookies are filled with weird gotchas and uncomfortable behavior that works 99.95% of the time. My favorite cookie minefield is cookie shadowing - if you set cookies with the same name but different key properties (domain, path, etc.) you can get multiple near-identical cookies set at once - with no ability for the backend or JS to tell which is which. Try going to https://example.com/somepath and entering the follow…
Using the path field is a code smell