4 ms·

Something I read in the RFC for email message format (or maybe elsewhere, but I have it associated with email for some reason) is: to be strict in output that y

by megous 6y ago

Something I read in the RFC for email message format (or maybe elsewhere, but I have it associated with email for some reason) is: to be strict in output that you produce, and lenient in the input you accept. I think it makes some sense for data formats, if you want max compatibility of independently developed software that processes the data. Not sure about APIs though. Having them fail fast on unexpected input is pretty valuable.

showerst 6y ago
I used to be a big fan of 'strict send, lenient accept', but looking at systems built on it -- (html, email), I think being lenient around format deviation just turns everything into a big mess. Granted those are two of the most successful technologies ever, so perhaps it was the right call =).
- megous 6y ago
  But html and email are also incredibly successful... so hmm?
tynorf 6y ago
I believe being lenient in accepting input is what leads to SSRF attacks (HTTP request smuggling via disagreeing `transfer-encoding` and `content-length` headers).
chrismorgan 6y ago
That’s Postel’s robustness principle. Many people now believe it was a harmful idea that actually achieves the opposite of what it was intended to achieve. https://tools.ietf.org/html/draft-iab-protocol-maintenance-04 https://tools.ietf.org/html/draft-iab-protocol-maintenance-0... expounds. (I confess I rather liked the earlier name of the draft, postel-was-wrong.)
- greggman3 6y ago
  Plenty of people have also argued that being strict on input would be bad https://web.archive.org/web/20060613193727/http://diveintomark.org/archives/2004/01/14/thought_experiment https://web.archive.org/web/20060613193727/http://diveintoma... https://friendlybit.com/html/why-xhtml-is-a-bad-idea/ https://friendlybit.com/html/why-xhtml-is-a-bad-idea/
  - chrismorgan 6y ago
    Those arguments are inapplicable here. They’re arguing against XHTML’s particular form of strictness and its failure mode, when compared with HTML, given that both are available to you the web developer; they are not arguing against strictness itself. (Also: if browsers had always rejected invalid documents, rather than having the HTML/XHTML split where one was liberal and one strict, I think we’d have had fewer problems, especially around injection bugs, and people would have been more careful about how they wrote their documents; but that’s fairly subjective.) If you can choose whether your platform supports strict or forgiving behaviour, security interests will side with strict every time. And indeed, HTML is no longer loose but rather strict in this protocol sense that we’re talking about, as it defines how all inputs should be parsed, leaving no scope for being liberal in what you accept. (It may surprise people, but among specs of at least moderate complexity, HTML is by far the strictest out there that I know of. I wish more specs were as strict. Actually, JavaScript is probably fairly close.) Also from the links of dissenting opinions at the start of the dive into mark link, https://web.archive.org/web/20060616150034/http://bitworking.org/news/There_are_no_exceptions_to_Postel_s_Law_ https://web.archive.org/web/20060616150034/http://bitworking... has a good discussion of just where Postel’s law may seem most reasonable to be applicable and inapplicable, with its two-axis (text–binary, data–language) diagram. It’s worth reading and contemplating.

by megous 6y ago

showerst 6y ago

I used to be a big fan of 'strict send, lenient accept', but looking at systems built on it -- (html, email), I think being lenient around format deviation just turns everything into a big mess. Granted those are two of the most successful technologies ever, so perhaps it was the right call =).

megous 6y ago
But html and email are also incredibly successful... so hmm?

tynorf 6y ago

I believe being lenient in accepting input is what leads to SSRF attacks (HTTP request smuggling via disagreeing `transfer-encoding` and `content-length` headers).

chrismorgan 6y ago

That’s Postel’s robustness principle. Many people now believe it was a harmful idea that actually achieves the opposite of what it was intended to achieve. https://tools.ietf.org/html/draft-iab-protocol-maintenance-04 https://tools.ietf.org/html/draft-iab-protocol-maintenance-0... expounds. (I confess I rather liked the earlier name of the draft, postel-was-wrong.)

greggman3 6y ago
Plenty of people have also argued that being strict on input would be bad https://web.archive.org/web/20060613193727/http://diveintomark.org/archives/2004/01/14/thought_experiment https://web.archive.org/web/20060613193727/http://diveintoma... https://friendlybit.com/html/why-xhtml-is-a-bad-idea/ https://friendlybit.com/html/why-xhtml-is-a-bad-idea/
- chrismorgan 6y ago
  Those arguments are inapplicable here. They’re arguing against XHTML’s particular form of strictness and its failure mode, when compared with HTML, given that both are available to you the web developer; they are not arguing against strictness itself. (Also: if browsers had always rejected invalid documents, rather than having the HTML/XHTML split where one was liberal and one strict, I think we’d have had fewer problems, especially around injection bugs, and people would have been more careful about how they wrote their documents; but that’s fairly subjective.) If you can choose whether your platform supports strict or forgiving behaviour, security interests will side with strict every time. And indeed, HTML is no longer loose but rather strict in this protocol sense that we’re talking about, as it defines how all inputs should be parsed, leaving no scope for being liberal in what you accept. (It may surprise people, but among specs of at least moderate complexity, HTML is by far the strictest out there that I know of. I wish more specs were as strict. Actually, JavaScript is probably fairly close.) Also from the links of dissenting opinions at the start of the dive into mark link, https://web.archive.org/web/20060616150034/http://bitworking.org/news/There_are_no_exceptions_to_Postel_s_Law_ https://web.archive.org/web/20060616150034/http://bitworking... has a good discussion of just where Postel’s law may seem most reasonable to be applicable and inapplicable, with its two-axis (text–binary, data–language) diagram. It’s worth reading and contemplating.