Hadn't seen that law before. Absolutely hate it. The harm from poor input invalidation over time is massive.

You have to think about Postel's law in terms of protocols and mistakes in your implementation. You assume your implementation isn't perfect and neither is the other. Do your best to be perfect and if you get something that isn't quite right, do your best to handle it well. That doesn't mean you don't validate inputs, it means that if data should come with a \n but instead comes with \n\r, you should treat it as a \n.

I think you miss their point which is that has led to a large number of security bugs. Because it is then path to exploits and sloppiness which then cannot be corrected because of backward compatibility or such.

Anyone else remember the time, years ago, when someone introduced a new performance feature to TCP, using an otherwise-unused bit in the header. Unfortunately, rolling it out turned into a giant clusterfuck because many routers on the internet interpreted "this bit is unused" as "this bit will always be zero"?

Ah yes, the fyranny of the middlebox.

Postel's Law isn't why we can't correct errors for backwards compatibility reasons.

We can't correct those because backwards compatibility is necessary to creating a global network that lasts decades. It's the railway effect... One simply can't expect every player to update their architecture religiously because they can't afford to, therefore what is made public tends to stick around for ages, and anything that fails to recognize that stickiness (IPv6 is my go to example) does so at its own peril.

Hyrum's Law is the near reverse of Postel's and i think it should be taught.

I imagine that it made more sense when your update cycle involved the postal system and took months.

Indeed, it's what got us "quirks mode" and that took years and years to dig the internet out from under.

I tried to split the difference with my April Fool's RFC, which proposes the HTTP status "397 Tolerating" for when you want to say "yeah, I know what you want, and I'll give you that, but here's how you were supposed to ask for it".

https://pastebin.com/TPj9RwuZ

I am borderline sad that this is only an RFC.

The number of services I use that I wish had a "warning" side-channel for letting me know something in my query was off, let me tell you...

There's nothing that says you can't have system messages as a boilerplate part of response bodies, even if you don't populate it.

In fact, it's the recommended way to do things like tell a client things it might need to know. Example: "The game servers will be shutting down in 15 minutes for maintenance."

True, but that means it has to be an ad hoc solution for every API instead of a standard.

It's not even an RFC, it's just a pastebin post pretending to be one.

Heh, after I posted it, a former co-worker forgot that was just an April Fool's joke and then, at his new workplace, seriously suggested handling one case by "throwing a 397".

I think Postel is misrepresented. It was addressed to programmers who anally rejected everything that was not (in their opinion) in spec.

Working code and rough consensus is how we progress.

> It was addressed to programmers who anally rejected everything that was not (in their opinion) in spec.

What's wrong with that? The only issue I see is the _in their opinion_ bit. If there's confusion about the spec, then it should clarified and codified. But otherwise: yes, you should absolutely aggressively reject everything not in spec.