News for hackers. Stuff that matters.
Re:Strict APIs vs. Forgiving APIs by megous on Wednesday October 28, 2020 @12:00PM (#24920339)
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.

Re:Strict APIs vs. Forgiving APIs by chrismorgan on Wednesday October 28, 2020 @12:48PM (#24921014)
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-0... expounds. (I confess I rather liked the earlier name of the draft, postel-was-wrong.)
Re:Strict APIs vs. Forgiving APIs by greggman3 on Wednesday October 28, 2020 @03:11PM (#24922898)
Re:Strict APIs vs. Forgiving APIs by chrismorgan on Wednesday October 28, 2020 @03:46PM (#24923309)
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... 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.

Re:Strict APIs vs. Forgiving APIs by showerst on Wednesday October 28, 2020 @12:03PM (#24920379)
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 =).

Re:Strict APIs vs. Forgiving APIs by megous on Wednesday October 28, 2020 @03:10PM (#24922883)
But html and email are also incredibly successful... so hmm?
Re:Strict APIs vs. Forgiving APIs by tynorf on Wednesday October 28, 2020 @12:08PM (#24920442)
I believe being lenient in accepting input is what leads to SSRF attacks (HTTP request smuggling via disagreeing `transfer-encoding` and `content-length` headers).