Hacker News new | past | comments | ask | show | jobs | submit login

I would say Postel's Law, "Be conservative in what you send, be liberal in what you accept," should be tempered a bit. Sometimes it makes sense to be a bit more liberal with what you send (to make sure that consumers can handle errors) and more strict with what you accept (to make sure that consumers aren't relying too much on undocumented behavior).

For example, if you have a service with near 100% uptime, any other service which relies on it may not be able to handle errors or unavailability. Introducing errors in a controlled way can help make the dependencies more reliable.

As another example, being liberal about what you accept can sometimes result in security flaws, since different systems might be interpreting a message differently. Rejecting malformed input can be a beautiful thing.




Postel's Law is about handling standard protocols.

If you control all the clients and servers using a protocol, it does not apply to you. You're better being as strict as possible.


I know what Postel’s law is about, the argument stands. Postel said that in 1989 and our thinking about protocols has changed a bit since then. If you’re implementing a standard protocol like HTTP or TLS, and you are liberal in what you accept, this can cause security problems or other unintended behavior. For example, consider a proxy or gateway that interprets a request differently from an authoritative server. Suppose a nonstandard request is handled differently by each component. Ideally, one of the responses is, "this request is malformed, reject it". If each component handles the same request differently but without rejecting the request, you are quite possibly in a world of hurt.

More concrete example: suppose that an incoming HTTP request contains CRLFLF. To the proxy, “liberal in what you accept” might mean that this is interpreted as CRLF CRLF, which is the end of the request header. To the authoritative server, perhaps the second LF is silently discarded and ignored. Voilà: instant cache poisoning attack.




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: