7 ms·

Regarding point 2, I think we need to consider Postel's Law a design antipattern, rather than a hallmark of good design. From now on, good software should not b

Regarding point 2, I think we need to consider Postel's Law a design antipattern, rather than a hallmark of good design. From now on, good software should not be permissive in what it accepts, because there is no good way to guarantee that such permissiveness will not lead to security breaches down the line.

eudox 10y ago
Additionally, being conservative in what you accept forces people to be conservative in what they emit upstream. Win-win!
- unlinker 10y ago
  Tell that to HTML engines ;P
  - catnaroek 10y ago
    Has any browser implementor ever given it a serious try?
    - seba_dos1 10y ago
      XHTML?
      - catnaroek 10y ago
        That wasn't serious enough. Did any browser ever reject a Web page just because it wasn't well-formed XHTML? Basically, give people a hand, and they'll grab your whole arm. It's human nature, and Web developers aren't above it.
        unlinker 10y ago
        That would be madness. Imagine a browser that did that, or that crashed the tab in case of a JS error. There would be no pages left :P
        catnaroek 10y ago
        It would be a lot more sensible than you think. When I get a compilation error, what I do is take a breath, think about the meaning of my code, correct any logical mistakes I can find, and try to compile again. Why couldn't Web developers do the same? Also, there's no need to crash the tab. The browser could simply stop running any JavaScript, and leave the user with a static page.
        Klathmon 10y ago
        IIRC some of the older versions of internet explorer did something like that, showing the user a popup if an error happened and asked them if they wanted to keep going.
        catnaroek 10y ago
        Next, browsers will show users a popup asking if they want to jump off a cliff.
        regularfry 10y ago
        And this is precisely the point. If the very earliest browsers had insisted on correctness rather than permissively accepting broken HTML (and JS - see semicolon insertion), we would not now have a situation where browsers need to do a ton of work to allow graceful degradation in the face of awful markup, simply because the tooling would have evolved in the other direction. Postel's Law gains a little temporary sender convenience in exchange for a nasty mess of permanent receiver headaches.
        DanBC 10y ago
        Postel's law has two parts. Be gracious in what you receive is what most people are talking about, but be cautious in what you send is just as important. If people are using broken markup that's the problem that needs fixing. How many web devs bother with validation anymore? (And not for app like functionality, but for what should be simple text and images with a few menus - why are so many newspaper websites so awful?) https://tools.ietf.org/html/rfc793 https://tools.ietf.org/html/rfc793 2.10. Robustness Principle TCP implementations will follow a general principle of robustness: be conservative in what you do, be liberal in what you accept from others.
        seba_dos1 10y ago
        >Did any browser ever reject a Web page just because it wasn't well-formed XHTML? Of course. If you served XHTML properly (by setting "application/xhtml+xml" MIME type), ill-formed XHTML would just show you a big syntax error instead of the page. Try it, that's still the case. Even when being well-formed, lots of sites still used "text/html" type to trigger HTML (SGML) parser instead of XML one, as any 3rd party code embedded into the website would of course crash the page as well. That was one of the reasons why XHTML never got popular and eventually has been abandoned.
        catnaroek 10y ago
        That still wasn't serious enough. All it took to get browsers to accept non-XHTML pages was to change the MIME type. What I'm talking about is simply not displaying ill-formed pages at all, under any circumstances.
        seba_dos1 10y ago
        But with that MIME type it wasn't XHTML at all. It was being parsed as HTML which was possible only because of big similarity between those two formats. All you need to ensure the behavior you want is to disable HTML parsing (which is pretty much ensures being liberal in what the parser accepts already in its specification).
      - alanh 10y ago
        Reply to sibling: “Did any browser reject poorly formed XHTML?” Yes, they did, if the XHTML was served with a MIME type of application/xhtml+xml. However, this MIME type was extremely rare because MSIE would not show a web page unless the MIME type was text/html. Furthermore, the extreme brittleness of XHTML was generally regarded as a Bad Move as one single URL in your source code with a literal ampersand instead of & would cause a complete and total breakage of your web page. Of course, many web pages are crummily concatenated strings and there are a lot of web devs who would never be able to reliably generate 100% XHTML-compliant output. Shit, pasting in a snippet of HTML where the BR tags omitted the self-closing slash would break your XHTML validation. tl;dr: Yes, and it sucked
        catnaroek 10y ago
        See second reply to seba_dos1.
GrumpyYoungMan 10y ago
I would disagree with that greatly. Postel's law says there's no need to excessively constrain what's considered valid input, not to ignore basic bounds checking and security. Not following Postel's law would result in brittle system components that break when other parts of the system evolve.
- eudox 10y ago
  >Not following Postel's law would reult in brittle system components that break when other parts of the system evolve. Being liberal in what you accept is precisely the definition of brittle: if there's an update that reduces the set of representable input data, but you keep the code that processes the user's input into data, then an untested, little-used edge case could invalidate your assumptions about the rest of the system.
- pbh101 10y ago
  >Not following Postel's law would result in brittle system components that break when other parts of the system evolve. This depends how much graceful degradation you have available to you. In systems/domains where little is available, following Postel's law can result in silent failures rather than explicit/loud ones. The question isn't whether they break or how brittle they are, but whether you will notice whether they did break. Each system exists within a range on a continuum of how acceptable Postel's law is.
  - catnaroek 10y ago
    Also, just because Postel's law worked for a small group of highly skilled systems programmers implementing common infrastructure for everyone, it doesn't automatically follow that it will work for a large and fast growing group of programmers of wildly varying skill, each implementing their own or their employer's brilliant business idea.
  - deleted 10y ago
    [deleted]
saidajigumi 10y ago
Counterpoint: Literally the only thing that allows forward compatibility on the web is permissiveness. When a browser sees something like this in CSS, .foo { someprop: boring-old-value; someprop: awesome-new-value; } instead of old browsers that don't understand just throwing a fit and dying, they ignore stuff they don't understand and carry on. So we know that a browser which doesn't implement 'someprop: awesome-new-value' will go ahead and read 'someprop: boring-old-value' instead of stopping processing of the CSS, or worse, emitting an error and refusing to render the page altogether. Without this, it would effectively be impossible to ship new web features until old browsers had died off to <epsilon-of-users-we-don't-care-about>.
- ashearer 10y ago
  There's a crucial distinction to be made. Ignoring unknown properties is a defined part of the CSS spec, so implementing it that way is just being correct. Postel's Law leads to trouble when "being liberal" means unilaterally extending the spec in ill-defined and ultimately incompatible ways. Example: autocorrecting "awesome-new-value" to its closest known match "alternative-old-value".
  - saidajigumi 10y ago
    I'll agree that Postel's Law should not be interpreted as "when something doesn't fit, force it". The most effective examples tend to have a duality: areas where permissiveness is allowed and areas where it's constrained. (E.g. The CSS/JSON must be well-formed, but the properties can vary.) Getting underneath the patterns and anti-patterns of permissiveness in an informed way is a lot more useful IMO than the knee-jerk reaction of declaring all permissiveness harmful and running away. Especially in light of the web's incredible wins via this strategy.
    - catnaroek 10y ago
      From a purely financial point of view, you may well be right: the technical and social benefits of clean, elegant, reliable, correct software probably don't justify sacrificing something as profitable as the permissiveness of the Web. But these are pretty damn twisted priorities. A little bit of social responsibility wouldn't hurt.

eudox 10y ago

Additionally, being conservative in what you accept forces people to be conservative in what they emit upstream. Win-win!

unlinker 10y ago
Tell that to HTML engines ;P
- catnaroek 10y ago
  Has any browser implementor ever given it a serious try?
  - seba_dos1 10y ago
    XHTML?
    - catnaroek 10y ago
      That wasn't serious enough. Did any browser ever reject a Web page just because it wasn't well-formed XHTML? Basically, give people a hand, and they'll grab your whole arm. It's human nature, and Web developers aren't above it.
      - unlinker 10y ago
        That would be madness. Imagine a browser that did that, or that crashed the tab in case of a JS error. There would be no pages left :P
        catnaroek 10y ago
        It would be a lot more sensible than you think. When I get a compilation error, what I do is take a breath, think about the meaning of my code, correct any logical mistakes I can find, and try to compile again. Why couldn't Web developers do the same? Also, there's no need to crash the tab. The browser could simply stop running any JavaScript, and leave the user with a static page.
        Klathmon 10y ago
        IIRC some of the older versions of internet explorer did something like that, showing the user a popup if an error happened and asked them if they wanted to keep going.
        catnaroek 10y ago
        Next, browsers will show users a popup asking if they want to jump off a cliff.
        regularfry 10y ago
        And this is precisely the point. If the very earliest browsers had insisted on correctness rather than permissively accepting broken HTML (and JS - see semicolon insertion), we would not now have a situation where browsers need to do a ton of work to allow graceful degradation in the face of awful markup, simply because the tooling would have evolved in the other direction. Postel's Law gains a little temporary sender convenience in exchange for a nasty mess of permanent receiver headaches.
        DanBC 10y ago
        Postel's law has two parts. Be gracious in what you receive is what most people are talking about, but be cautious in what you send is just as important. If people are using broken markup that's the problem that needs fixing. How many web devs bother with validation anymore? (And not for app like functionality, but for what should be simple text and images with a few menus - why are so many newspaper websites so awful?) https://tools.ietf.org/html/rfc793 https://tools.ietf.org/html/rfc793 2.10. Robustness Principle TCP implementations will follow a general principle of robustness: be conservative in what you do, be liberal in what you accept from others.
      - seba_dos1 10y ago
        >Did any browser ever reject a Web page just because it wasn't well-formed XHTML? Of course. If you served XHTML properly (by setting "application/xhtml+xml" MIME type), ill-formed XHTML would just show you a big syntax error instead of the page. Try it, that's still the case. Even when being well-formed, lots of sites still used "text/html" type to trigger HTML (SGML) parser instead of XML one, as any 3rd party code embedded into the website would of course crash the page as well. That was one of the reasons why XHTML never got popular and eventually has been abandoned.
        catnaroek 10y ago
        That still wasn't serious enough. All it took to get browsers to accept non-XHTML pages was to change the MIME type. What I'm talking about is simply not displaying ill-formed pages at all, under any circumstances.
        seba_dos1 10y ago
        But with that MIME type it wasn't XHTML at all. It was being parsed as HTML which was possible only because of big similarity between those two formats. All you need to ensure the behavior you want is to disable HTML parsing (which is pretty much ensures being liberal in what the parser accepts already in its specification).
    - alanh 10y ago
      Reply to sibling: “Did any browser reject poorly formed XHTML?” Yes, they did, if the XHTML was served with a MIME type of application/xhtml+xml. However, this MIME type was extremely rare because MSIE would not show a web page unless the MIME type was text/html. Furthermore, the extreme brittleness of XHTML was generally regarded as a Bad Move as one single URL in your source code with a literal ampersand instead of & would cause a complete and total breakage of your web page. Of course, many web pages are crummily concatenated strings and there are a lot of web devs who would never be able to reliably generate 100% XHTML-compliant output. Shit, pasting in a snippet of HTML where the BR tags omitted the self-closing slash would break your XHTML validation. tl;dr: Yes, and it sucked
      - catnaroek 10y ago
        See second reply to seba_dos1.

GrumpyYoungMan 10y ago

I would disagree with that greatly. Postel's law says there's no need to excessively constrain what's considered valid input, not to ignore basic bounds checking and security. Not following Postel's law would result in brittle system components that break when other parts of the system evolve.

eudox 10y ago
>Not following Postel's law would reult in brittle system components that break when other parts of the system evolve. Being liberal in what you accept is precisely the definition of brittle: if there's an update that reduces the set of representable input data, but you keep the code that processes the user's input into data, then an untested, little-used edge case could invalidate your assumptions about the rest of the system.
pbh101 10y ago
>Not following Postel's law would result in brittle system components that break when other parts of the system evolve. This depends how much graceful degradation you have available to you. In systems/domains where little is available, following Postel's law can result in silent failures rather than explicit/loud ones. The question isn't whether they break or how brittle they are, but whether you will notice whether they did break. Each system exists within a range on a continuum of how acceptable Postel's law is.
- catnaroek 10y ago
  Also, just because Postel's law worked for a small group of highly skilled systems programmers implementing common infrastructure for everyone, it doesn't automatically follow that it will work for a large and fast growing group of programmers of wildly varying skill, each implementing their own or their employer's brilliant business idea.
- deleted 10y ago
  [deleted]

saidajigumi 10y ago

Counterpoint: Literally the only thing that allows forward compatibility on the web is permissiveness. When a browser sees something like this in CSS, .foo { someprop: boring-old-value; someprop: awesome-new-value; } instead of old browsers that don't understand just throwing a fit and dying, they ignore stuff they don't understand and carry on. So we know that a browser which doesn't implement 'someprop: awesome-new-value' will go ahead and read 'someprop: boring-old-value' instead of stopping processing of the CSS, or worse, emitting an error and refusing to render the page altogether. Without this, it would effectively be impossible to ship new web features until old browsers had died off to <epsilon-of-users-we-don't-care-about>.

ashearer 10y ago
There's a crucial distinction to be made. Ignoring unknown properties is a defined part of the CSS spec, so implementing it that way is just being correct. Postel's Law leads to trouble when "being liberal" means unilaterally extending the spec in ill-defined and ultimately incompatible ways. Example: autocorrecting "awesome-new-value" to its closest known match "alternative-old-value".
- saidajigumi 10y ago
  I'll agree that Postel's Law should not be interpreted as "when something doesn't fit, force it". The most effective examples tend to have a duality: areas where permissiveness is allowed and areas where it's constrained. (E.g. The CSS/JSON must be well-formed, but the properties can vary.) Getting underneath the patterns and anti-patterns of permissiveness in an informed way is a lot more useful IMO than the knee-jerk reaction of declaring all permissiveness harmful and running away. Especially in light of the web's incredible wins via this strategy.
  - catnaroek 10y ago
    From a purely financial point of view, you may well be right: the technical and social benefits of clean, elegant, reliable, correct software probably don't justify sacrificing something as profitable as the permissiveness of the Web. But these are pretty damn twisted priorities. A little bit of social responsibility wouldn't hurt.