Postel's law is considered more and more harmful as the industry evolved.

CodesInChaos 11 hours ago | parent | next [-]

That depends on how Postel's law is interpreted.

What's reasonable is: "Set reserved fields to 0 when writing and ignore them when reading." (I heard that was the original example). Or "Ignore unknown JSON keys" as a modern equivalent.

What's harmful is: Accept an ill defined superset of the valid syntax and interpret it in undocumented ways.

▲

tuetuopay 9 hours ago | parent | next [-]

Funny I never read the original example. And in my book, it is harmful, and even worse in JSON, since it's the best way to have a typo somewhere go unnoticed for a long time.

	▲	sweetjuly 7 hours ago \| parent [-]
		The original example is very common in ISAs at least. Both ARMv8 and RISC-V (likely others too but I don't have as much experience with them) have the idea of requiring software to treat reserved bits as if they were zero for both reading and writing. ARMv8 calls this RES0 and an hardware implementation is constrained to either being write ignore for the field (eg read is hardwired to zero) or returning the last successful write. This is useful as it allows the ISA to remain compatible with code which is unaware of future extensions which define new functionality for these bits so long as the zero value means "keep the old behavior". For example, a system register may have an EnableNewFeature bit, and older software will end up just writing zero to that field (which preserves the old functionality). This avoids needing to define a new system register for every new feature.

▲

treve 10 hours ago | parent | prev | next [-]

Good modern protocols will explicitly define extension points, so 'ingoring unknown JSON keys' is in-spec rather than assumed that an implementer will do.

▲

yxhuvud 9 hours ago | parent | prev [-]

I disagree. I find accepting extra random bytes in places to be just as harmful. I prefer APIs that push back and tell me what I did wrong when I mess up.

▲

n2d4 11 hours ago | parent | prev | next [-]

Very much so. A better law would be conservative in both sending and accepting, as it turns out that if you are liberal in what you accept, senders will choose to disobey Postel's law and be liberal in what they send, too.

▲

mikestorrent 9 hours ago | parent | next [-]

It's an oscillation. It goes in cycles. Things formalize upward until you've reinvented XML, SOAP and WSDLs; then a new younger generation comes in and says "all that stuff is boring and tedious, here's this generation's version of duck typing", followed by another ten years of tacking strong types onto that.

MCP seems to be a new round of the cycle beginning again.

	▲	Ericson2314 3 hours ago \| parent [-]
		No they won't do that, because vibe coding boring tedious shit is easy and looks good to your manager. I'm dead serious, we should be in a golden age of "programming in the large" formal protocols.

▲

Gigachad 8 hours ago | parent | prev [-]

The modern view seems to be you should just immediately abort if the spec isn't being complied with since it's possibly someone trying to exploit the system with malformed data.

▲

esafak 11 hours ago | parent | prev [-]

I think it is okay to accept liberally as long as you combine it with warnings for a while to give offenders a chance to fix it.

▲

hdjrudni 11 hours ago | parent | next [-]

"Warnings" are like the most difficult thing to 'send' though. If an app or service doesn't outright fail, warnings can be ignored. Even if not ignored... how do you properly inform? A compiler can spit out warnings to your terminal, sure. Test-runners can log warnings. An RPC service? There's no standard I'm aware of. And DNS! Probably even worse. "Yeah, your RRs are out of order but I sorted them for you." where would you put that?

▲

esafak 11 hours ago | parent | next [-]

> how do you properly inform?

Through the appropriate channels; in-band and out-of-band.

	▲	immibis 8 hours ago \| parent [-]
		a content-less tautology

▲

diarrhea 10 hours ago | parent | prev [-]

Randomly fail or (increasingly) delay a random subset of all requests.

▲

Melonai 9 hours ago | parent [-]

That sounds awful and will send administrators on a wild goose chase throughout their stack to find the issue without many clues except this thing is failing at seemingly random times. (I myself would suspect something related to network connectivity, maybe requests are timing out? This idea would lead me in the completely wrong direction.)

It also does not give any way to actually see a warning message, where would we even put it? I know for a fact that if my glibc DNS resolver started spitting out errors into /var/log/god_knows_what I would take days to find it, at best the resolver could return some kind of errno with perror giving us a message like "The DNS response has not been correctly formatted", and then hope that the message is caught and forwarded through whatever is wrapping the C library, hopefully into our stderr. And there's so many ways even that could fail.

	▲	SahAssar 7 hours ago \| parent [-]
		So we arrive at the logical conclusion: You send errors in morse code, encoded as seconds/minutes of failures/successes. Any reasonable person would be able to recognize morse when seeing the patterns on a observability graph. Start with milliseconds, move on to seconds and so on as the unwanted behavior continues.

▲

psnehanshu 11 hours ago | parent | prev | next [-]

Warnings are ignored. It's much better to fail fast.

▲

dotancohen 11 hours ago | parent | prev [-]

The Python 3 community was famously divided on that matter, wrt Python 3. Now that it is over, most people on the "accept liberally" side of the fence have jumped sides.