3 ms·

HTTP 2 is faster though. Especially over mobile networks. Simple doesn't always mean better.

by Jonnax 6y ago

p_l 6y ago
Not just "simple" - broken, like all "bang it out on pseudo serial port" protocols of IETF nature. The text nature makes it easy to implement a broken client or server in a hobbled development environment, yes. It also creates a legacy of brammage that is impossible to fix without significant break in protocol like HTTP/2 is. Shortly speaking, Postel's Law Considered Harmful (in network protocols, at least)
- mrighele 6y ago
  > It also creates a legacy of brammage that is impossible to fix without significant break in protocol like HTTP/2 is. Isn't also HTTP/3 a significant break in protocol compared do HTTP/2 ?
  - p_l 6y ago
    From what I remember on HTTP/3 vs HTTP/2,main differences are due to different transport layer - in fact yiu can even use QUIC without HTTP. The HTTP part are mostly lifted from HTTP/2
- jart 6y ago
  IETF protocols being YOLO is exactly what makes them so attractive. The web never would have been a thing if it needed to be built on something highly correct and ordered like Signalling System No. 7.
  - p_l 6y ago
    SS7 is pretty bad comparison. OSI stack is better, but usually you'd build on top of higher-level components of it, not "supposedly text but honestly binary" protocol like HTTP. Being YOLO resulted in it taking over 15 years for email to not have random crashes involving my native language (and it's pretty simple, as it has no multibyte requirements). YOLO is how the internet has been broken through multi-level NAT, because ca 1980 someone convinced other that for "temporary test deployment" only 32bits will manage. YOLO is why transition to IPv6 takes ages even when higher level protocol wouldn't even notice, because ~1983 in panic someone made an emergency, student-made port of TOPS-20 TCP/IPv4 interface and we're left picking the pieces forever. And yes, HTTP and other "text" protocols are essentially binary protocols, because you end up dealing with whatever binary constant form someone put into client/server code. If someone goes too far into treating it as text when sending, suddenly you have a problem of dealing with missing record terminators. Standard header names could be just as well binary, except there's extra variation both possible (if you want to follow Postel's law), and spec (details of encoding).
    - jart 6y ago
      I'm sorry you lost your faith in the Internet. If it makes you feel any better, I'm a Hurricane Electric certified IPv6 sage and I implement text-based telecommunications protocols so well that even Chinese operators use my code, because they like to implement creative extensions like the ones you describe, and the stuff I write is just so generalized that it can smoothly / easily enable that multitude of visions. Why? Is it because I'm unique? No. It's simply because my work follows the same free-spiritedness that's always guided IETF publications. They built us the best of all possible internets, and nothing, including IPv4 address exhaustion, is going to change that.

HTTP 2 is faster though. Especially over mobile networks. Simple doesn't always mean better.

by Jonnax 6y ago

HTTP 2 is faster though. Especially over mobile networks. Simple doesn't always mean better.

p_l 6y ago

Not just "simple" - broken, like all "bang it out on pseudo serial port" protocols of IETF nature. The text nature makes it easy to implement a broken client or server in a hobbled development environment, yes. It also creates a legacy of brammage that is impossible to fix without significant break in protocol like HTTP/2 is. Shortly speaking, Postel's Law Considered Harmful (in network protocols, at least)

mrighele 6y ago
> It also creates a legacy of brammage that is impossible to fix without significant break in protocol like HTTP/2 is. Isn't also HTTP/3 a significant break in protocol compared do HTTP/2 ?
- p_l 6y ago
  From what I remember on HTTP/3 vs HTTP/2,main differences are due to different transport layer - in fact yiu can even use QUIC without HTTP. The HTTP part are mostly lifted from HTTP/2
jart 6y ago
IETF protocols being YOLO is exactly what makes them so attractive. The web never would have been a thing if it needed to be built on something highly correct and ordered like Signalling System No. 7.
- p_l 6y ago
  SS7 is pretty bad comparison. OSI stack is better, but usually you'd build on top of higher-level components of it, not "supposedly text but honestly binary" protocol like HTTP. Being YOLO resulted in it taking over 15 years for email to not have random crashes involving my native language (and it's pretty simple, as it has no multibyte requirements). YOLO is how the internet has been broken through multi-level NAT, because ca 1980 someone convinced other that for "temporary test deployment" only 32bits will manage. YOLO is why transition to IPv6 takes ages even when higher level protocol wouldn't even notice, because ~1983 in panic someone made an emergency, student-made port of TOPS-20 TCP/IPv4 interface and we're left picking the pieces forever. And yes, HTTP and other "text" protocols are essentially binary protocols, because you end up dealing with whatever binary constant form someone put into client/server code. If someone goes too far into treating it as text when sending, suddenly you have a problem of dealing with missing record terminators. Standard header names could be just as well binary, except there's extra variation both possible (if you want to follow Postel's law), and spec (details of encoding).
  - jart 6y ago
    I'm sorry you lost your faith in the Internet. If it makes you feel any better, I'm a Hurricane Electric certified IPv6 sage and I implement text-based telecommunications protocols so well that even Chinese operators use my code, because they like to implement creative extensions like the ones you describe, and the stuff I write is just so generalized that it can smoothly / easily enable that multitude of visions. Why? Is it because I'm unique? No. It's simply because my work follows the same free-spiritedness that's always guided IETF publications. They built us the best of all possible internets, and nothing, including IPv4 address exhaustion, is going to change that.