3 ms·

My suspicion is that this article is looking at the problem through "HTTP"-colored glasses. Just because that protocol is going through continuous development

My suspicion is that this article is looking at the problem through "HTTP"-colored glasses. Just because that protocol is going through continuous development does not mean all other protocols are doing so as well. The driving force here is the reluctance of the web community to use ports other than 80/443 for the newer versions of the HTTP protocols. While HTTP/2 and HTTP/3 are superficially similar to HTTP/1, the fact is that the protocols are different and should have been given different port numbers.

gpderetta 5y ago
I think that's a consequence of another network principle: default deny. In practice anything that doesn't look like a standard and common protocol gets firewalled out into oblivion at some stage or other: first anything that doesn't look like TCP, and if you are lucky UDP, then block everything but well known ports. Then block anything that doesn't look like HTTP, and so on and on. So we end up with a matrioska stack of encapsulated protocols.
- c-linkage 5y ago
  To default deny everything other than HTTP is patently absurd and it should not be used as an excuse for poor engineering. The security argument is poor at best, and dangerous at worst. The fact that one can SSH over HTTP means organizations are no more secure than if they just allowing direct SSH access. Forcing everything over HTTP serves to obfuscate what could be dangerous traffic (SSH-based exfiltration) as innocuous web-browsing. The real way to implement default deny is to block everything except that which is required. If new ports were required for HTTP2 and HTTP3 then you would simply open those ports. If you didn't want to support HTTP/1 because it's unencrypted and it closes the connection after each request you would block port 80 and be done with it. Instead, we build super-complex software that changes its behavior based on a version string in a GET request.
  - gpderetta 5y ago
    I agree completely, but often that's the reality for protocol designers.
pornel 5y ago
It is an RFC, and these tend to be about network protocols… HTML <= 4 used to follow this principle, and turned out to be a non-interoperable mess. It needed an intervention in the form of HTML5. Although it may seem that HTML5 embraces the robustness principle, it's more of a workaround for it: it exactly defines how to handle any input, even "garbage" one, leaving implementers no room for flexibility, so there are no undefined inputs left to be liberal about (XHTML is also defined for all possible inputs with no ambiguity, they only differ in what they prescribe for handling of the "bad" ones). Non-network things decay too. For example, there's no useful spec for GIF. Real-world files depend on specific bugs, like misinterpretation of frame rate or spec-incorrect handling of backgrounds.
- horsawlarway 5y ago
  Yes, and when your protocol is almost 30 years old and has most of the true quirks and edge cases ironed out because nearly everyone with a computer uses it - I think adopting a more strict approach can make sense. That said - there's a reason this draft wasn't adopted: it doesn't make sense in most other areas (and certainly wouldn't have made sense for http and some of these protocols even 20 years ago). The reality of technology is almost everyone gives zero fucks about how good your standard/protocol is - they want to use it to do something genuinely useful. --- To summarize: The initial argument of this draft states "The posture this statement advocates promotes interoperability in the short term, but can negatively affect the protocol ecosystem over time." My rebuttal is: Interoperability in the short term FAR OUTWEIGHS negative consequences in the long term, and should be prioritized for any protocol which has not yet seen wide and robust adoption.
- c-linkage 5y ago
  Browser interpretations of HTML are a indeed a hot mess. However, HTTP and HTML tend to grow together. By assigning new ports to HTTP/2 and HTTP/3 (and the versions of HTML that are prevalent at the time the protocols are released), older browsers that are not receiving updates would be completely unaware of the new ports and would only connect to the ports used for older versions where the clients would happily exist in their "I'm going to interpret things my way" world. When connecting to the new ports, browsers would have to agree to abide by the new well-defined and strict specifications. As support for HTTP/1 (and the associated older versions of HTML) disappeared, the HTTP/1 servers would either be shut down or configured to server redirects to the HTTP/2 and HTTP/3 content. In the latter case, should the client continue to issue HTTP/1 request to HTTP/2 servers, the server would send a "Version not supported" message telling the client to upgrade.
jcranmer 5y ago
Having worked on the email side of things, the problems mentioned here are exactly as painful there as it is for HTTP. The problem with the robustness principle is that it is heavily misinterpreted in practice. The original intent was to remind implementors to be wary of ambiguity in specifications, but in practice, it has often been taken to mean that implementors must try to scavenge as much understanding as possible from flagrant violations of the specification.

gpderetta 5y ago

I think that's a consequence of another network principle: default deny. In practice anything that doesn't look like a standard and common protocol gets firewalled out into oblivion at some stage or other: first anything that doesn't look like TCP, and if you are lucky UDP, then block everything but well known ports. Then block anything that doesn't look like HTTP, and so on and on. So we end up with a matrioska stack of encapsulated protocols.

c-linkage 5y ago
To default deny everything other than HTTP is patently absurd and it should not be used as an excuse for poor engineering. The security argument is poor at best, and dangerous at worst. The fact that one can SSH over HTTP means organizations are no more secure than if they just allowing direct SSH access. Forcing everything over HTTP serves to obfuscate what could be dangerous traffic (SSH-based exfiltration) as innocuous web-browsing. The real way to implement default deny is to block everything except that which is required. If new ports were required for HTTP2 and HTTP3 then you would simply open those ports. If you didn't want to support HTTP/1 because it's unencrypted and it closes the connection after each request you would block port 80 and be done with it. Instead, we build super-complex software that changes its behavior based on a version string in a GET request.
- gpderetta 5y ago
  I agree completely, but often that's the reality for protocol designers.

pornel 5y ago

It is an RFC, and these tend to be about network protocols… HTML <= 4 used to follow this principle, and turned out to be a non-interoperable mess. It needed an intervention in the form of HTML5. Although it may seem that HTML5 embraces the robustness principle, it's more of a workaround for it: it exactly defines how to handle any input, even "garbage" one, leaving implementers no room for flexibility, so there are no undefined inputs left to be liberal about (XHTML is also defined for all possible inputs with no ambiguity, they only differ in what they prescribe for handling of the "bad" ones). Non-network things decay too. For example, there's no useful spec for GIF. Real-world files depend on specific bugs, like misinterpretation of frame rate or spec-incorrect handling of backgrounds.

horsawlarway 5y ago
Yes, and when your protocol is almost 30 years old and has most of the true quirks and edge cases ironed out because nearly everyone with a computer uses it - I think adopting a more strict approach can make sense. That said - there's a reason this draft wasn't adopted: it doesn't make sense in most other areas (and certainly wouldn't have made sense for http and some of these protocols even 20 years ago). The reality of technology is almost everyone gives zero fucks about how good your standard/protocol is - they want to use it to do something genuinely useful. --- To summarize: The initial argument of this draft states "The posture this statement advocates promotes interoperability in the short term, but can negatively affect the protocol ecosystem over time." My rebuttal is: Interoperability in the short term FAR OUTWEIGHS negative consequences in the long term, and should be prioritized for any protocol which has not yet seen wide and robust adoption.
c-linkage 5y ago
Browser interpretations of HTML are a indeed a hot mess. However, HTTP and HTML tend to grow together. By assigning new ports to HTTP/2 and HTTP/3 (and the versions of HTML that are prevalent at the time the protocols are released), older browsers that are not receiving updates would be completely unaware of the new ports and would only connect to the ports used for older versions where the clients would happily exist in their "I'm going to interpret things my way" world. When connecting to the new ports, browsers would have to agree to abide by the new well-defined and strict specifications. As support for HTTP/1 (and the associated older versions of HTML) disappeared, the HTTP/1 servers would either be shut down or configured to server redirects to the HTTP/2 and HTTP/3 content. In the latter case, should the client continue to issue HTTP/1 request to HTTP/2 servers, the server would send a "Version not supported" message telling the client to upgrade.

jcranmer 5y ago

Having worked on the email side of things, the problems mentioned here are exactly as painful there as it is for HTTP. The problem with the robustness principle is that it is heavily misinterpreted in practice. The original intent was to remind implementors to be wary of ambiguity in specifications, but in practice, it has often been taken to mean that implementors must try to scavenge as much understanding as possible from flagrant violations of the specification.