30 ms·

Most out-in-the-wild usage of zip files fits the 'Robustness Principle', or, after its author, Postel's Law, found in RFC 1122 [1]: > Be liberal in what you ac

by niftich 10y ago

Most out-in-the-wild usage of zip files fits the 'Robustness Principle', or, after its author, Postel's Law, found in RFC 1122 [1]: > Be liberal in what you accept, and conservative in what you send There are several analyses of this maxim and whether it's a good choice for designing robust, secure systems. This particular Internet Draft doesn't agree [2]. [1] https://tools.ietf.org/html/rfc1122#section-1.2.2 https://tools.ietf.org/html/rfc1122#section-1.2.2 [2] https://tools.ietf.org/html/draft-thomson-postel-was-wrong-00 https://tools.ietf.org/html/draft-thomson-postel-was-wrong-0...

user5994461 10y ago
For user interfaces: Be liberal in what you accept from the user. For M2M (machine to machine): Be strict in what you accept, and strict in what you send. That's my take on it now. For instance, a user will copy/paste URLs to his browser, there will probably be a space too much before or after. It's okay to clean it (and a better experience than a "site not found"). When a machine sends something "weird". Well, it's not possible to know if it's really wrong and it can't be corrected in any meaningful way. Just fail and throw an error so the developer can fix it.
- wolrah 10y ago
  I agree with those positions, but what about the middle ground? Browsers for example, taking machine-to-machine data which sometimes is human generated. I'm a fan of the strict solution as far as that goes, but there's a reason XHTML failed. Somehow asking people who write web sites to do it right or else it doesn't work is a big deal.
  - taneq 10y ago
    The best approach seems to be to be strict in what you accept, and strict in what you emit, and if you want your software to be forgiving to the vagaries of human input, then strictly adhere to a forgiving spec.
  - Too 10y ago
    The difference is a user interface translates the non strict version to the strict version instantly once you click the submit button. A hand written html file is stored persistently, retaining the flaw for all future.
  - user5994461 10y ago
    Well. How to say that without being dismissive of the average web hobbyist... Well, when the job is to accept a hugely complex flexible poorly defined input format from 30 years ago that is written by millions of people who have no clue what they are doing, fixing common errors and getting anything to render is part of the spec ^^ And... oh wait! I said "Be liberal in what you accept from the user" when it comes to user input. Web pages are user input, so yeah, browsers are no exception to the rules, they're actually a perfect example! :D
  - chrismorgan 10y ago
    If the web had been strict from the start, we would never have had a problem: people would never have been publishing invalid documents because browsers would have been rejecting them outright. XHTML failed because HTML existed and was good enough.
- taeric 10y ago
  No. You should always be as liberal on what you accept as you can. Primarily because as strict as you try to be in what you send, you are likely to make mistakes. Very very likely. Obviously, your field of work dictates a lot here. And, if you are accepting something that has severe consequences on acting out, then yes, be more strict. However, the general principal holds. In general.
  - user5994461 10y ago
    > Primarily because as strict as you try to be in what you send, you are likely to make mistakes. Very very likely. What you call a human mistake should be called a bug. The only acceptable way to handle a bug is to fix the code. Not to be dismissive but the way you think is a classic beginner mistake. It's not the responsibility of other software to guess what bugs you'll put in yours. ^^ > Obviously, your field of work dictates a lot here. large distributed systems, financial exchanges, trading systems, national government projects, aerospace, and even web stuff at times. Some fields have low standards. That doesn't mean that the good practises don't apply, it just mean that people don't apply them ;)
    - taeric 10y ago
      I conceded it is a bug. I merely claimed you will make some. Because, you will. Period. You also have an odd misconception. It isn't having lower standards to be liberal in what you accept. It is actually harder. Much harder. And you should do it. Easy example from finance. You shouldn't just take one currency. You should take in as many currencies as you can understand. Does this mean to be magical? No. But you should ask, "how many different ways could this be given to me?" And you should instrument this with a marker for "unexpected."
      - user5994461 10y ago
        > You shouldn't just take one currency. You should take in as many currencies as you can understand. This is a business feature request. The "Being liberal about what you accept" is a technical guideline for protocol/format design and input processing/sanitation. Don't apply that rule to feature requests, it's not meant for that :(
vacri 10y ago
As an aside, a couple of months ago I found out that the PHP ISO8601 timestamp format is not 8601 compliant. If you want an ISO8601 timestamp, you have to use a different format. I'm not sure how this fits in with Postel's law, but your comment jogged my memory of it :) http://php.net/manual/en/class.datetime.php http://php.net/manual/en/class.datetime.php
- Terr_ 10y ago
  MySQL utf8 isn't utf8 either :p
flukus 10y ago
I wonder how many security exploits this principle is responsible for?

by niftich 10y ago

user5994461 10y ago

For user interfaces: Be liberal in what you accept from the user. For M2M (machine to machine): Be strict in what you accept, and strict in what you send. That's my take on it now. For instance, a user will copy/paste URLs to his browser, there will probably be a space too much before or after. It's okay to clean it (and a better experience than a "site not found"). When a machine sends something "weird". Well, it's not possible to know if it's really wrong and it can't be corrected in any meaningful way. Just fail and throw an error so the developer can fix it.

wolrah 10y ago
I agree with those positions, but what about the middle ground? Browsers for example, taking machine-to-machine data which sometimes is human generated. I'm a fan of the strict solution as far as that goes, but there's a reason XHTML failed. Somehow asking people who write web sites to do it right or else it doesn't work is a big deal.
- taneq 10y ago
  The best approach seems to be to be strict in what you accept, and strict in what you emit, and if you want your software to be forgiving to the vagaries of human input, then strictly adhere to a forgiving spec.
- Too 10y ago
  The difference is a user interface translates the non strict version to the strict version instantly once you click the submit button. A hand written html file is stored persistently, retaining the flaw for all future.
- user5994461 10y ago
  Well. How to say that without being dismissive of the average web hobbyist... Well, when the job is to accept a hugely complex flexible poorly defined input format from 30 years ago that is written by millions of people who have no clue what they are doing, fixing common errors and getting anything to render is part of the spec ^^ And... oh wait! I said "Be liberal in what you accept from the user" when it comes to user input. Web pages are user input, so yeah, browsers are no exception to the rules, they're actually a perfect example! :D
- chrismorgan 10y ago
  If the web had been strict from the start, we would never have had a problem: people would never have been publishing invalid documents because browsers would have been rejecting them outright. XHTML failed because HTML existed and was good enough.
taeric 10y ago
No. You should always be as liberal on what you accept as you can. Primarily because as strict as you try to be in what you send, you are likely to make mistakes. Very very likely. Obviously, your field of work dictates a lot here. And, if you are accepting something that has severe consequences on acting out, then yes, be more strict. However, the general principal holds. In general.
- user5994461 10y ago
  > Primarily because as strict as you try to be in what you send, you are likely to make mistakes. Very very likely. What you call a human mistake should be called a bug. The only acceptable way to handle a bug is to fix the code. Not to be dismissive but the way you think is a classic beginner mistake. It's not the responsibility of other software to guess what bugs you'll put in yours. ^^ > Obviously, your field of work dictates a lot here. large distributed systems, financial exchanges, trading systems, national government projects, aerospace, and even web stuff at times. Some fields have low standards. That doesn't mean that the good practises don't apply, it just mean that people don't apply them ;)
  - taeric 10y ago
    I conceded it is a bug. I merely claimed you will make some. Because, you will. Period. You also have an odd misconception. It isn't having lower standards to be liberal in what you accept. It is actually harder. Much harder. And you should do it. Easy example from finance. You shouldn't just take one currency. You should take in as many currencies as you can understand. Does this mean to be magical? No. But you should ask, "how many different ways could this be given to me?" And you should instrument this with a marker for "unexpected."
    - user5994461 10y ago
      > You shouldn't just take one currency. You should take in as many currencies as you can understand. This is a business feature request. The "Being liberal about what you accept" is a technical guideline for protocol/format design and input processing/sanitation. Don't apply that rule to feature requests, it's not meant for that :(

vacri 10y ago

As an aside, a couple of months ago I found out that the PHP ISO8601 timestamp format is not 8601 compliant. If you want an ISO8601 timestamp, you have to use a different format. I'm not sure how this fits in with Postel's law, but your comment jogged my memory of it :) http://php.net/manual/en/class.datetime.php http://php.net/manual/en/class.datetime.php

Terr_ 10y ago
MySQL utf8 isn't utf8 either :p

flukus 10y ago

I wonder how many security exploits this principle is responsible for?