10 ms·

Misunderstood principle. Liberal does NOT mean Malformed. As you say, all behaviors should be fully specced, and inputs that violate that spec should rightly b

by hhas01 7y ago

Misunderstood principle. Liberal does NOT mean Malformed. As you say, all behaviors should be fully specced, and inputs that violate that spec should rightly be rejected. It’s the spec itself that should be forgiving. e.g. Don’t require fields for which sensible defaults can be assumed. Don’t be needlessly anal about case and white space variations. Maintain backwards-compatibility by continuing to accept older input formats alongside the latest and greatest. Accept ints where floats are expected. And so on. HTTP is a good application. Whereas the eejits who invented HTML have a helluva lot to answer for.

kazinator 7y ago
Yes, the principle does actually mean that nonconforming inputs should be accepted. Well, only if someone has decided that their meaning is clear. But that is rarely so if you're outside of the spec. The intended meaning of a bunch of bits (syntax) can be anything, or nothing at all. Sensible defaults can't be assumed; they have to be specified. My sensible may be your silly. If a spec defines certain parameters, and neglects to say anything about their defaults, and an implemention assumes defaults, that will cause issues. Firstly, the user will break if they go to another implementation which rejects their data. It's not that implementation's fault; it's just catching the error of missing values with unspecified defaults. Worse, the user's data can silently be interpreted with some different defaults. You have to be exactly as anal about case and white space variations as the spec says. A C compiler or linker can't treat PrintF as printf just because the meaning seems clear enough, and PrintF has not been declared or defined. > Whereas the eejits who invented HTML have a helluva lot to answer for. In my original version of the comment I used HTML as an example, but decided to omit that. The problem wasn't the invention of it (though that doesn't escape criticism) but rather the fact that during early Web history and during the first Browser War era, browsers tried to accept non-conforming HTML and render it anyway. Thus people writing bad HTML had no feedback. The pages looked good with whatever browser they tested with. So browsers had to scramble to reverse engineer and imitate each other's handling of bad HTML as good. The effects of that situation persist; it's not fully resolved. That will happen with any interchange or storage format, if treated with Postel's principle. Postel's principle is from the point of view of keeping the internet working, in a situation where messages pass through multiple hosts, which are inaccessible to either the sender or the receiver. If something is rejected due to violating a rule, there is no diagnosis; the symptom looks the same like a severed cable at the bottom of the ocean. It's understandable where that came from. Postel's principle somewhat applies to intermediary data handlers. If you're just routing messages, and see a message that you don't understand, then just pass it along. The principle should be "have as little effect as possible; look at only the parts of data needed to do your job, and don't interpret and act on payloads that don't belong to you; try hard to route rather than drop."

by hhas01 7y ago

kazinator 7y ago

Yes, the principle does actually mean that nonconforming inputs should be accepted. Well, only if someone has decided that their meaning is clear. But that is rarely so if you're outside of the spec. The intended meaning of a bunch of bits (syntax) can be anything, or nothing at all. Sensible defaults can't be assumed; they have to be specified. My sensible may be your silly. If a spec defines certain parameters, and neglects to say anything about their defaults, and an implemention assumes defaults, that will cause issues. Firstly, the user will break if they go to another implementation which rejects their data. It's not that implementation's fault; it's just catching the error of missing values with unspecified defaults. Worse, the user's data can silently be interpreted with some different defaults. You have to be exactly as anal about case and white space variations as the spec says. A C compiler or linker can't treat PrintF as printf just because the meaning seems clear enough, and PrintF has not been declared or defined. > Whereas the eejits who invented HTML have a helluva lot to answer for. In my original version of the comment I used HTML as an example, but decided to omit that. The problem wasn't the invention of it (though that doesn't escape criticism) but rather the fact that during early Web history and during the first Browser War era, browsers tried to accept non-conforming HTML and render it anyway. Thus people writing bad HTML had no feedback. The pages looked good with whatever browser they tested with. So browsers had to scramble to reverse engineer and imitate each other's handling of bad HTML as good. The effects of that situation persist; it's not fully resolved. That will happen with any interchange or storage format, if treated with Postel's principle. Postel's principle is from the point of view of keeping the internet working, in a situation where messages pass through multiple hosts, which are inaccessible to either the sender or the receiver. If something is rejected due to violating a rule, there is no diagnosis; the symptom looks the same like a severed cable at the bottom of the ocean. It's understandable where that came from. Postel's principle somewhat applies to intermediary data handlers. If you're just routing messages, and see a message that you don't understand, then just pass it along. The principle should be "have as little effect as possible; look at only the parts of data needed to do your job, and don't interpret and act on payloads that don't belong to you; try hard to route rather than drop."