6 ms·

The article mocks Postel's law, but if the setter of the cookie had been conservative in what they sent, there would have been no need for the article...

marcosdumay 2y ago
The problem with Postel's law is exactly that the sender is never conservative, and will tend to use any detail that most receivers accept.
- somat 2y ago
  So the problem with Postel's law is that people don't follow Postel's law?
  - marcosdumay 2y ago
    The problem is that it's a prisoner's dilemma. And you can't cooperate on a prisoner's dilemma against the entire world.
    - ndusart 2y ago
      So, just be as conservative as possible when you produce data and as liberal as possible when you receive something. Your code will then require the least cooperation from *any* other code to be compatible with. Doing otherwise will require cooperation to adjust on the specificities clients expect, and you fall into the trap of the prisoner dilemna.
      - marcosdumay 2y ago
        No, when you create a protocol define exactly what you need what is optional and what is an error, and stick to that. Being liberal on what you accept is a path for disaster.
        ndusart 2y ago
        You changed the problem. Postel's law is not about writing the protocol but implementing it. Sure, protocol should be designed to be as specific as possible but unfortunately these are not always defined up to that point for any good or bad reasons, and we generally are at best just in the implementation side and cannot influence the writing of the protocol, so the Postel's law is the best we can apply to avoid having to cooperate with the rest of the planet.
        marcosdumay 2y ago
        From wikipedia: > The principle is also known as Postel's law, after Jon Postel, who used the wording in an early specification of TCP.
        ndusart 2y ago
        From the mentioned specification: > TCP implementations should follow a general principle of robustness: be conservative in what you do, be liberal in what you accept from others. Better to look in the sources ;)
Sohcahtoa82 2y ago
> The article mocks Postel's law As they should. Postel's Law was a terrible idea and has created minefields all over the place. Sometimes, those mines aren't just bugs, but create gaping security holes. If your client is sending data that doesn't conform to spec, you have a bug, and you need to fix it. It should never be up to the server to figure out what you meant and accept it.
- rendall 2y ago
  [flagged]
- SilasX 2y ago
  You could split the difference with a 397 TOLERATING response, which lets you say "okay I'll handle that for now, but here's what you were supposed to do, and I'll expect that in the future". (j/k it's an April Fool's parody) https://pastebin.com/TPj9RwuZ https://pastebin.com/TPj9RwuZ
- emn13 2y ago
  And yet the html5 syntax variation survived (with all it's weird now-codified quirks), and the simpler, stricter xhtml died out. I'm not disagreeing with out; it's just that being flexible, even if it's bad for the ecosystem is good for surviving in the ecosystem.
  - plorkyeran 2y ago
    There was a lot of pain and suffering along the way to html5, and html5 is the logical end state of postel's law: every possible sequence of bytes is a valid html5 document with a well-defined parsing, so there is no longer any room to be more liberal in what you accept than what the standard permits (at least so far as parsing the document).
    - emn13 2y ago
      Getting slightly off topic, but I think it's hard to find the right terminology to talk about html's complexities. As you point out, it isn't really a syntax anymore now that literally every sequence is valid. Yet the parsing rules are obviously not as simple as a .* regex. It's syntactically simple, but structurally complex? What's the right term for the complexity represented by how the stack of open elements interacts with self-closing or otherwise special elements? Anyhow, I can't say I'm thrilled that some deeply nested subtree of divs for instance might be closed by a open-button tag just because they were themselves part of a button, except when... well, lots of exceptions. It's what we have, I guess. It's also not a (fully) solved problem; just earlier this year I had to work around an issue in the chromium html parser that caused IIRC quadratic parsing behavior in select items with many options. That's probably the most widely used parser in the world, and a really inanely simple repro. I wonder whether stuff like that would slip through as often were the parsing rules at all sane. And of course encapsulation of a document-fragment is tricky due to the context-sensitivity of the parsing rules; many valid DOM trees don't have an HTML serialization.

marcosdumay 2y ago

The problem with Postel's law is exactly that the sender is never conservative, and will tend to use any detail that most receivers accept.

somat 2y ago
So the problem with Postel's law is that people don't follow Postel's law?
- marcosdumay 2y ago
  The problem is that it's a prisoner's dilemma. And you can't cooperate on a prisoner's dilemma against the entire world.
  - ndusart 2y ago
    So, just be as conservative as possible when you produce data and as liberal as possible when you receive something. Your code will then require the least cooperation from *any* other code to be compatible with. Doing otherwise will require cooperation to adjust on the specificities clients expect, and you fall into the trap of the prisoner dilemna.
    - marcosdumay 2y ago
      No, when you create a protocol define exactly what you need what is optional and what is an error, and stick to that. Being liberal on what you accept is a path for disaster.
      - ndusart 2y ago
        You changed the problem. Postel's law is not about writing the protocol but implementing it. Sure, protocol should be designed to be as specific as possible but unfortunately these are not always defined up to that point for any good or bad reasons, and we generally are at best just in the implementation side and cannot influence the writing of the protocol, so the Postel's law is the best we can apply to avoid having to cooperate with the rest of the planet.
        marcosdumay 2y ago
        From wikipedia: > The principle is also known as Postel's law, after Jon Postel, who used the wording in an early specification of TCP.
        ndusart 2y ago
        From the mentioned specification: > TCP implementations should follow a general principle of robustness: be conservative in what you do, be liberal in what you accept from others. Better to look in the sources ;)

Sohcahtoa82 2y ago

> The article mocks Postel's law As they should. Postel's Law was a terrible idea and has created minefields all over the place. Sometimes, those mines aren't just bugs, but create gaping security holes. If your client is sending data that doesn't conform to spec, you have a bug, and you need to fix it. It should never be up to the server to figure out what you meant and accept it.

rendall 2y ago
[flagged]
SilasX 2y ago
You could split the difference with a 397 TOLERATING response, which lets you say "okay I'll handle that for now, but here's what you were supposed to do, and I'll expect that in the future". (j/k it's an April Fool's parody) https://pastebin.com/TPj9RwuZ https://pastebin.com/TPj9RwuZ
emn13 2y ago
And yet the html5 syntax variation survived (with all it's weird now-codified quirks), and the simpler, stricter xhtml died out. I'm not disagreeing with out; it's just that being flexible, even if it's bad for the ecosystem is good for surviving in the ecosystem.
- plorkyeran 2y ago
  There was a lot of pain and suffering along the way to html5, and html5 is the logical end state of postel's law: every possible sequence of bytes is a valid html5 document with a well-defined parsing, so there is no longer any room to be more liberal in what you accept than what the standard permits (at least so far as parsing the document).
  - emn13 2y ago
    Getting slightly off topic, but I think it's hard to find the right terminology to talk about html's complexities. As you point out, it isn't really a syntax anymore now that literally every sequence is valid. Yet the parsing rules are obviously not as simple as a .* regex. It's syntactically simple, but structurally complex? What's the right term for the complexity represented by how the stack of open elements interacts with self-closing or otherwise special elements? Anyhow, I can't say I'm thrilled that some deeply nested subtree of divs for instance might be closed by a open-button tag just because they were themselves part of a button, except when... well, lots of exceptions. It's what we have, I guess. It's also not a (fully) solved problem; just earlier this year I had to work around an issue in the chromium html parser that caused IIRC quadratic parsing behavior in select items with many options. That's probably the most widely used parser in the world, and a really inanely simple repro. I wonder whether stuff like that would slip through as often were the parsing rules at all sane. And of course encapsulation of a document-fragment is tricky due to the context-sensitivity of the parsing rules; many valid DOM trees don't have an HTML serialization.