7 ms·

Even HTTP/2 seems to have been rushed[1]. Chrome has removed support for server push. Maybe more thought should be put into these protocols instead of just rebr

• surajrmal 2y ago
  It's okay to make mistakes, that's how you learn and improve. Being conservative has drawbacks of its own. Id argue we need more parties involved earlier in the process rather than just time.
  • zdragnar 2y ago
    It's a weird balancing act. On the other hand, waiting for everyone to agree on everything means that the spec will take a decade or two for everyone to come together, and then all the additional time for everyone to actively support it. AJAX is a decent example. Microsoft's Outlook Web Access team implemented XMLHTTP as an activex thing for IE 5 and soon the rest of the vendors adopted it as a standard thing as XmlHttpRequest objects. In fact, I suspect the list of things that exist in browsers because one vendor thought it was a good idea and everyone hopped on board is far, far longer than those designed by committee. Often times, the initially released version is not exactly the same that everyone standardized on, but they all get to build on the real-world consequences of it. I happen to like the TC39 process https://tc39.es/process-document/ https://tc39.es/process-document/ which requires two live implementations with use in the wild for something to get into the final stage and become an official part of the specification. It is obviously harder for something like a network stack than a JavaScript engine to get real world use and feedback, but it has helped to keep a lot of the crazier vendor specific features at bay.
  • arcbyte 2y ago
    It's okay to make mistakes, but its not okay to ignore the broad consensus that HTTP2 was TERRIBLY designed and then admit it 10 years later as if it was unknowable. We knew it was bad.
• deleted 2y ago
  [deleted]
• est 2y ago
  I don't blame Google, all major version changes are very brave, I praised them. The problem is lack of non-google protocols for competition.
  • pas 2y ago
    Cloudflare seems to be pushing eSNI and HTTPS (SVCB) DNS record type. for a while there was a lot of research coming out form various institutions on congestion control, that's how we got CoDel, no?
• KaiserPro 2y ago
  HTTP2 was a prototype that was designed by people who either assumed that mobile internet would get better much quicker than it did, or who didn't understand what packet loss did to throughput. I suspect part of the problem is that some of the rush is that people at major companies will get a promotion if they do "high impact" work out in the open. HTTP/2 "solves head of line blocking" which is doesn't. It exchanged an HTTP SSL blocking issues with TCP on the real internet issue. This was predicted at the time. The other issue is that instead of keeping it a simple protocol, the temptation to add complexity to aid a specific use case gets too much. (It's human nature I don't blame them)
  • pornel 2y ago
    H/2 doesn't solve blocking it on the TCP level, but it solved another kind of blocking on the protocol level by having multiplexing. H/1 pipelining was unusable, so H/1 had to wait for a response before sending the next request, which added a ton of latency, and made server-side processing serial and latency-sensitive. The solution to this was to open a dozen separate H/1 connections, but that multiplied setup cost, and made congestion control worse across many connections.
    • KaiserPro 2y ago
      > it solved another kind of blocking on the protocol level Indeed! and it works well on low latency, low packet loss networks. On high packet loss networks, it performs worse than HTTP1.1. Moreover it gets increasingly worse the larger the page the request is serving. We pointed this out at the time, but were told that we didn't understand the web. > H/1 pipelining was unusable, Yup, but think how easy it would be to create http1.2 with better spec for pipe-lining. (but then why not make changes to other bits as well, soon we get HTTP2!) But of course pipelining only really works in a low packet loss network, because you get head of line blocking. > open a dozen separate H/1 connections, but that multiplied setup cost Indeed, that SSL upgrade is a pain in the arse. But connections are cheap to keep open. So with persistent connections and pooling its possible to really nail down the latency. Personally, I think the biggest problem with HTTP is that its a file access protocol, a state interchange protocol and an authentication system. I would tentatively suggest that we adopt websockets to do state (with some extra features like optional schema sharing {yes I know thats a bit of enanthema}) Make http4 a proper file sharing prototcol and have a third system for authentication token generation, sharing and validation. However the real world says that'll never work. So connection pooling over TCP with quick start TLS would be my way forward.
• liveoneggs 2y ago
  Part of/Evidence of the Google monopoly position in the web stack are these big beta tests of protocols they cook up for whatever reason.
  • surajrmal 2y ago
    This is a weak argument that simply caters to the ongoing HN hivemind opinion. While Google made the initial proposal, many other parties did participate in getting quic standardized. The industry at large was in favor.
    • oefrha 2y ago
      IETF QUIC ended up substantially different from gQUIC. People who say Google somehow single-handedly pushed things through probably haven’t read anything along the standardization process, but of course everyone has to have an opinion about all things Google.
• cryptonector 2y ago
  Server push is not really what H/2 is about.