3 ms·

Didn't really understand the linked blog posts, but "Parse Don't Validate" sounds like another way of stating Postel's Maxim, which is to be liberal in what you

by jart 5y ago

Didn't really understand the linked blog posts, but "Parse Don't Validate" sounds like another way of stating Postel's Maxim, which is to be liberal in what you accept but conservative in what you send. I generally try to follow that principle with the way I've written the redbean web server. When it comes to things like URLs and HTTP messages, there's a whole bunch of characters in each field that the RFCs say aren't allowed, but the parser code is still able to work fine even if they're permitted. For example, the RFC says ` isn't allowed in a path, but why should the parser care? It's not like that's a syntactic element. There's no reason to consult a map of validate characters, which slows things down, until you want to re-encode the parsed URL. The re-encoded version will turn the parsed ` into %60 since that's what you might send back to the network, and that needs to be perfect, since you don't know if the other end has one of those strict as a matter of policy parsers, that ignore what's possible and enforces only what's legal.

Iazel 5y ago
Hey there, I wonder if this article I wrote about the same concept would make it more clear? It's on medium, but free :) https://pelligra-s.medium.com/parse-dont-validate-in-kotlin-afbac505a04f https://pelligra-s.medium.com/parse-dont-validate-in-kotlin-... I honestly think the two arguments are different though. We could say that Postel's Maxim is about "how much you should parse/validate", while the problem we are addressing is rather "how you should do it" :)
- jart 5y ago
  Oh I see. You define parsing more in the yacc sense. Carry on. I've been working with char arrays too long.
IshKebab 5y ago
I'm not sure if you're aware but Postel's Maxim is fairly universally viewed as a huge mistake. It leads to security issues and poor reliability.
- jart 5y ago
  Says you. There's an Internet draft where some guy from Mozilla basically said "Postel was wrong; the solution is to always be conservative" https://datatracker.ietf.org/doc/html/draft-iab-protocol-maintenance https://datatracker.ietf.org/doc/html/draft-iab-protocol-mai... However it's a draft so he only speaks for himself; it's not Internet law. He also doesn't get it. Deviancy being ignored by a parser shouldn't be interpreted as intent to support. Non-conforming use cases are accepted at the pleasure of the implementor. Consider this. The Internet never would have become popular and inclusive like it became if it was designed to be highly strict, structured, and ordered like Signalling System 7. I like the fact that a 14 year kid can write an HTTP client or server, if they want to, and if they do it'll most likely be mostly correct. Stuff like that makes people fall in love with the Internet from the earliest ages. If we look at the history of companies like DEC vs. PC it's pretty clear technology can't survive >1 generation when there's no career track for hobbyists. In some cases deviancy in protocols has helped standards become better. Consider HTML. If we had things Tim Berners Lee's way, we'd all be writing ugly verbose XHTML that validates. It wasn't until HTML5 that W3C embraced the chaos of the true standard and formalized the non-conformant use-cases (such as being able to omit <html>, <head>, </tr> </td>, </p>, etc.) and it made the HTML language much more pleasant. So we should take the concerns of the "always be conservative" crowd with a grain of salt. Because they're the people who wanted XHTML. They're the people who ban numbers like 0xC0,0x80 because some version of some Oracle or Microsoft piece software had a bug once. I don't like how people who embrace policies like that invariably write code that destroys text data in some misguided effort to keep people safe from themselves. There should be better reasons for preventing things which are possible from happening.
  - IshKebab 5y ago
    > Says you. Says lots of people. I actually wasn't even aware of that draft RFC you linked. > we'd all be writing ugly verbose XHTML that validates And you think that's a bad thing???!! > It wasn't until HTML5 that W3C embraced the chaos of the true standard and formalized the non-conformant use-cases (such as being able to omit <html>, <head>, </tr> </td>, </p>, etc.) and it made the HTML language much more pleasant. That is a crazy rewriting of history! > I like the fact that a 14 year kid can write an HTTP client or server, if they want to, and if they do it'll most likely be mostly correct. What I don't even... Have you seen HTTP?

by jart 5y ago

Iazel 5y ago

Hey there, I wonder if this article I wrote about the same concept would make it more clear? It's on medium, but free :) https://pelligra-s.medium.com/parse-dont-validate-in-kotlin-afbac505a04f https://pelligra-s.medium.com/parse-dont-validate-in-kotlin-... I honestly think the two arguments are different though. We could say that Postel's Maxim is about "how much you should parse/validate", while the problem we are addressing is rather "how you should do it" :)

jart 5y ago
Oh I see. You define parsing more in the yacc sense. Carry on. I've been working with char arrays too long.

IshKebab 5y ago

I'm not sure if you're aware but Postel's Maxim is fairly universally viewed as a huge mistake. It leads to security issues and poor reliability.

jart 5y ago
Says you. There's an Internet draft where some guy from Mozilla basically said "Postel was wrong; the solution is to always be conservative" https://datatracker.ietf.org/doc/html/draft-iab-protocol-maintenance https://datatracker.ietf.org/doc/html/draft-iab-protocol-mai... However it's a draft so he only speaks for himself; it's not Internet law. He also doesn't get it. Deviancy being ignored by a parser shouldn't be interpreted as intent to support. Non-conforming use cases are accepted at the pleasure of the implementor. Consider this. The Internet never would have become popular and inclusive like it became if it was designed to be highly strict, structured, and ordered like Signalling System 7. I like the fact that a 14 year kid can write an HTTP client or server, if they want to, and if they do it'll most likely be mostly correct. Stuff like that makes people fall in love with the Internet from the earliest ages. If we look at the history of companies like DEC vs. PC it's pretty clear technology can't survive >1 generation when there's no career track for hobbyists. In some cases deviancy in protocols has helped standards become better. Consider HTML. If we had things Tim Berners Lee's way, we'd all be writing ugly verbose XHTML that validates. It wasn't until HTML5 that W3C embraced the chaos of the true standard and formalized the non-conformant use-cases (such as being able to omit <html>, <head>, </tr> </td>, </p>, etc.) and it made the HTML language much more pleasant. So we should take the concerns of the "always be conservative" crowd with a grain of salt. Because they're the people who wanted XHTML. They're the people who ban numbers like 0xC0,0x80 because some version of some Oracle or Microsoft piece software had a bug once. I don't like how people who embrace policies like that invariably write code that destroys text data in some misguided effort to keep people safe from themselves. There should be better reasons for preventing things which are possible from happening.
- IshKebab 5y ago
  > Says you. Says lots of people. I actually wasn't even aware of that draft RFC you linked. > we'd all be writing ugly verbose XHTML that validates And you think that's a bad thing???!! > It wasn't until HTML5 that W3C embraced the chaos of the true standard and formalized the non-conformant use-cases (such as being able to omit <html>, <head>, </tr> </td>, </p>, etc.) and it made the HTML language much more pleasant. That is a crazy rewriting of history! > I like the fact that a 14 year kid can write an HTTP client or server, if they want to, and if they do it'll most likely be mostly correct. What I don't even... Have you seen HTTP?