No, it's terrible advice as it only causes unnecessary interoperability problems and vulnerabilities. There is no reason why anyone should need to generate invalid input to your program and it is never a better idea to make every consumer more complex to deal with broken input than to make one producer create non-broken output.
The only robustness to invalid input you should have is that you should not fall over when you encounter broken input, but simply reject it.
Both TCP which Postel wrote the spec and HTML follow this principle so it it seems have its merits.
You know what followed your principle? XHTML...and the arguments were the same, its not well formed just reject it, why would you ever accept broken input.
Sure it makes parsing faster and simpler and yet what actually works and is robust in the real world, HTML...
That HTML is a platform with an extraordinary security track record? Noone has ever exploited all the ambiguities that result from the incoherent mess that is the web?
Or is it that we never had any interoperability problems with HTML? All browsers always reliably rendered websites consistently? "This website is optimized for IE" never happened?
How isn't that just the best example to support my point?
As for TCP ... how is it relevant that Postel wrote the spec? Does that mean that the vulnerabilities in TCP never happened? Or are you saying that modern TCP implementations try to accept any crap whatsoever? (No, they don't, of course they don't, people have actually learned that that's a bad idea.)
People seem to prefer web sites that render inconsistently rather than not at all because of one little issue in the markup. It is more robust to render something rather than nothing and is one big reason XHTML was abandoned.
Yes a system that no one uses is more secure than one everybody does.
Postel's Law is literally in the TCP RFC [1], don't you think that makes it relevant?
> People seem to prefer web sites that render inconsistently rather than not at all because of one little issue in the markup.
Except those are not the alternatives. The alternatives are consistently rendered websites or inconsistently rendered websites. If browsers had strictly enforced HTML syntax from the beginning, noone would ever have built websites with "little issues in the markup".
IP stacks do not accept randomly misformatted IP packets. The result is obviously not that you constantly encounter internet services that you can not access because your IP stack is picky about broken IP packets, the result is that noone ever sends you broken IP packets.
> It is more robust to render something rather than nothing
No, it just isn't. You are just looking at a very small part of the consequences of this implementation strategy that indeed happens to be positive, but completely ignoring the big picture of all the externalities and other indirect damage that result from it.
> and is one big reason XHTML was abandoned.
Erm ... no? The reason why XHTML was abandoned was because people are incompetent at writing software, and there existed an alternative that allowed them to keep their idiotic practices, including all the vulnerabilities and interoperability problems that result from those, so that's what people did.
> Yes a system that no one uses is more secure than one everybody does.
How does that follow? And what does that have to do with anything?
> Postel's Law is literally in the TCP RFC [1], don't you think that makes it relevant?
>Except those are not the alternatives. The alternatives are consistently rendered websites or inconsistently rendered websites. If browsers had strictly enforced HTML syntax from the beginning, noone would ever have built websites with "little issues in the markup".
Thats not reality, if everyone got perfect formed input we wouldn't be having this debate, the reality is it occurs, so what do you do, reject it or accept it and try and do something with it. XHTML simply rejects malformed markup and you get a blank page, HTML tries to make sense of it and render something.
>IP stacks do not accept randomly misformatted IP packets. The result is obviously not that you constantly encounter internet services that you can not access because your IP stack is picky about broken IP packets, the result is that noone ever sends you broken IP packets.
So you never heard of ECN? The ECN bits being set where technically incorrect depending on how pedantic you where in the interpretation and some stacks rejected packets if the bits weren't set to zero. Due to he robustness principle most stacks ignored these bits allowing others to use them for ECN, allowing a graceful update to the spec. The stacks that took your stance however and rejected where simply roadblocks in the adoption.
>No, it just isn't. You are just looking at a very small part of the consequences of this implementation strategy that indeed happens to be positive, but completely ignoring the big picture of all the externalities and other indirect damage that result from it.
I'm not ignoring anything, I am just pointing out reality, the real world is messy and the stacks that try to keep working under messy conditions seem to be prevailing. Its not pretty and I don't deny the issues that arise, but here we are communicating on the largest most successful computer network ever built using a protocol and a markup language built with Postels law in mind.
>Erm ... no? The reason why XHTML was abandoned was because people are incompetent at writing software, and there existed an alternative that allowed them to keep their idiotic practices, including all the vulnerabilities and interoperability problems that result from those, so that's what people did.
I think most who know the history there would disagree with this opinion [1], it was obvious to me at the time why XHTML would fail even though I thought it a cleaner solution, I realized thats what was holding it back. It was much better to see your page come up with maybe a weird rendering artifact than just have the browser render nothing and throw an error if some small part was malformed.
>How does that follow? And what does that have to do with anything?
Because complaining about security vulnerabilities found in some of the most used software in the world while comparing to something that no one uses doesn't help your point.
>Relevant ... for what?
Uh gee I don't know maybe Postel's law is kinda relevant when discussing TCP because Postel wrote the spec you know like what you asked in the post before? What kind of game are you playing here?
It's good wisdom but beware the counter-argument. Being liberal in what you accept causes your implementation to have to maintain a wide range of implicitly defined odd inputs in perpetuity and leads to a form of lock-in based on handling of edge-cases. HTML and browser implementations that allowed all sorts of garbage behaviors are a good example of this. The robustness principle works, but it does come with a cost, like all things.
The only robustness to invalid input you should have is that you should not fall over when you encounter broken input, but simply reject it.