You’re talking about the Accept-Language header. They are asking about the cookie.
To answer the question, yes, normally you would have some kind of manual switcher that sets the cookie. Please don’t use flags for this, because flags indicate countries, not languages. Don’t make a Russian-speaking Ukrainian seek out the Russian flag, and don’t make an English-speaking Irish person seek out the Union Flag.
> To answer the question, yes, normally you would have some kind of manual switcher that sets the cookie. Please don’t use flags for this, because flags indicate countries, not languages. Don’t make a Russian-speaking Ukrainian seek out the Russian flag, and don’t make an English-speaking Irish person seek out the Union Flag.
Yes, why make things easy. :-)
Controversial opinion: Flags are great as a visual aid, shorthand, look neat, and give a better UX for 90+% of users, even if it hurts some linguists' and nationalists' feelings.
Its not just a matter of hurt feelings, it has multiple problems. If it was just hurt feelings I might agree with you, but it is ambiguous, inconsistent and fails to cover many cases. That is bad UI.
What flags to you suggest people use for Cantonese, Tamil, Arabic and Xhosa?
Why use the Union flag for English? If the language is en-US surely an American flag would be more accurate? You can then use the British flag for en-GB. However, if you offer Welsh you would use the Welsh flag (and presumably the Scottish one for Scottish Gaelic, although I cannot recall ever seeing that) so it would surely be more consistent to use the English flag for British? Even for or generic English?
I dunno, which flag would serve as a comprehensible shorthand for Arabic? How many Arabic readers would recognise that flag? How many Spanish speakers would recognise the Spanish flag?
If you use flags I would still recommend putting the language name in the language next to it, for example the French flag next to 'Français'.
But then where's the flag for Liberia and Belize and Singapore? What if I'm in Indonesia and you don't offer an Indonesian option but I know enough English to get by - what country's flag should I click?
Just don't use flags, man. It's ridiculous that this is even still a discussion.
I gave an example of Russian-speaking Ukrainians. Why are you characterising this as “hurting some linguists' and nationalists' feelings”? It’s not nationalism or pedantry to be offended at being forced to identify with the flag of the country that is currently murdering your friends and family.
I don't think it is a big problem given functions like fs.readFileSync already exists. It doesn't have to be a JS standard but be a server-side JS runtime specific function, which can be used when hacks are needed.
I agree. The blame belongs to the NodeJS steering committee. It's their failure and it's a big one.
The only excuse is that ESM happened during the big Deno Node wars when the community was split, everyone was mad and, apparently making dumb decisions.
I read that a new version of NodeJS has revised require() to bring in ESM modules. That's good enough. (I would prefer importSync() for clarity.)
Not sure if this is a bit off topic or not, but I recently encountered a problem where my program are continuously calling write to a socket in a loop that loops N times, with each of them sending about a few hundred bytes of data representing an application-level message. The loop can be understanded as some "batched messages" to server. After that, the program will try to receive data from server and do some processing.
The problem is that if N is above certain limit (e.g. 4), the server will resulting in some error saying that the data is truncated somehow. I want to make N larger because the round-trip latency is already high enough, so being blocked by this is pretty annoying. Eventually, I found an answer on stackoverflow saying that setting TCP_NODELAY can fix this, and it actually magically enable be to increase N to a larger number like 64 or 128 without causing issues. Still not sure why TCP_NODELAY can fix this issue and why this problem happens in the first place.
My guess would be that the server assumes that every call to recv() terminates on a message boundary.
With TCP_NODELAY and small messages, this works out fine. Every message is contained in a single packet, and the userspace buffer being read into is large enough to contain it. As such, whenever the kernel has any data to give to userspace, it has an integer number of messages to give. Nothing requires the kernel to respect that, but it will not go out of its way to break it.
In contrast, without TCP_NODELAY, messages get concatenated and then fragmented based on where packet boundaries occur. Now, the natural end point for a call to recv() is not the message boundary, but the packet boundary.
The server is supposed to see that it is in the middle of a message, and make another call to recv() to get the rest of it; but clearly it does not do that.
> The problem is that if N is above certain limit (e.g. 4), the server will resulting in some error saying that the data is truncated somehow.
Maybe your server expects full application-level messages from single "recv" call? This is is not correct. A message may be spited across multiple recv buffers.
The example given by parent does not need eval to trigger though. Just create a function and replace its code object then call it, it will easily segfault.
It sounds really really inconvenient when you have a lot of accounts on different websites. Imagine login to add new passkey andremove the old passkey for 100 websites (and my password manager already stores much more than 100 accounts).
Yes, I'm aware that it's very inconvenient. I did the same for my TOTP codes because Google Authenticator didn't restore your keys if your devices were different.
So, I had to manually migrate TOTP secrets from 30+ accounts back then, by removing 2FA, and re-enabling it with a new secret.
As I said before, it's a sliding scale trading off between security and convenience. Select your poison and its dosage, and do your own cocktail.
Or, providers will develop a workflow to migrate or add new devices easily. Like "validate on another validated device to add this new passkey" scheme.
I know, I use yubikeys for all my important stuff.
But I view passkeys as more for the low-hanging fruit. All the crap accounts that every webshop and news outlet makes you create these days. I have 500+ accounts in my current password manager. Not being able to migrate that away to another service would be a nightmare. Being locked in with a big tech company would be too.
What my ideal would be is to have the master key on multiple HSMs (like multiple yubikeys) so they are safe but mobile.
Also, if software password managers don't offer export options it doesn't mean it's impossible to export. They just don't want to make it possible. But an adversary could. The only way to really make it impossible is hardware tokens which is great for important stuff but not really for those thirteen in a dozen accounts.
Isn't it already supported by REST?
CREATE: POST
READ: GET (or QUERY if body is needed)
UPDATE: PUT for full update, PATCH for partial update
DELETE: DELETE
AFAIK, only SIDH-like schemes that exposes auxiliary points are broken, so others schemes like CSIDH may have some chances?
https://issikebrokenyet.github.io/
