7 ms·

Please don't implement HTTP/2 and HTTP/3. Unless you are working on Firefox or some other thing that should compete with Chrome. Complicated protocol, unfriend

by exo762 6y ago

Please don't implement HTTP/2 and HTTP/3. Unless you are working on Firefox or some other thing that should compete with Chrome. Complicated protocol, unfriendly to hackers, offering huge corporation some millisecond savings to enforce their walled garden supremacy.

londons_explore 6y ago
> offering huge corporation some millisecond savings millisecond savings for all their users, which adds up to saving man-years every day. It is literally preventing people wasting lifetimes of effort looking at loading spinners. If you can do better, propose it, but don't force other people to waste lifetimes of effort otherwise.
- krzyk 6y ago
  HTTP 1.1 was good for long, long time. It had major benefits like pure text protocol, that one could use even by doing telnet to webserver (I did that when I needed to debug some pesky issues), starting with HTTP 2.0 it all goes to binary protocol (there is a text one, but almost no browser supports it :( ). And now, on top of that replace years of performance tuning TCP out of the window and use UDP, and invent TCP features on top of UDP. Yes, it is faster (few percent, this is not a 50% increase, it is a mere 3%), but the benefits will be reaped by the largest of corporations. Is it worth it? Maybe for end users (who will get their web page in 485 ms instead of 500ms), but for developers it is not. I was expecting HTTP 3.0 to get us huge benefits, but the numbers that were posted few days ago in hacker news are so underwhelming that I just don't care for it at all. And cost of development is high.
  - kxrm 6y ago
    I am not sure I understand your concern, couldn't someone just develop a console app that can traverse the protocol? I am with you in the enjoyment of the simplicity of HTTP/1.1 but I don't agree that this particular concern is large enough to slow adoption.
    - yc12340 6y ago
      It is a complex, stateful (!!) protocol with non-trivial state-machine. A "console app" won't cut it. Even Wireshark might not cut it. Thanks to things like quick start, TLS session tickets and server push you won't understand what are you even looking on 90% of time. When HTTP 1.1 fails, your browser shows you a proper error message. When HTTP 2/3 fails, it is always "a protocol format violation". What violation? Why? Who knows. > I don't agree that this particular concern is large enough to slow adoption Sure thing. Kerberos is still alive and kicking. SMB 1 is built into every appliance. SOAP is the protocol of choice for corporations... Complexity never slows down adoption of <insert name of utter turd technology>, because such technology is generally being pushed down people's throats by someone else. If Google does not push HTTP 3 slower, it's adoption won't slow down. The quality of tech plays no role in that.
      - kxrm 6y ago
        I disagree with the idea that this is being "pushed down people's throats". It's another protocol and nothing has been published stating that HTTP/1.1 support is going anywhere. A protocol format violation notice could tell you what was wrong it just hasn't been developed to the full extent to do so. Give browsers and tools time to develop and be built to properly debug the connection.
  - onion2k 6y ago
    Maybe for end users (who will get their web page in 485 ms instead of 500ms), but for developers it is not. If the users see the benefit then the companies that the developers work for will find a new competitive advantage, which benefits the developers (higher profit, better job security, etc). It's impossible for one group to benefit without the other group also benefitting.
  - M2Ys4U 6y ago
    >but the benefits will be reaped by the largest of corporations. What isn't? But you're also ignoring the fact that these benefits will also be reaped by end-users - and more by people who have poor connections to the Internet. >Is it worth it? Maybe for end users (who will get their web page in 485 ms instead of 500ms), but for developers it is not. The Internet is for End Users,[0] not for developers. UX >>> DX. [0] https://tools.ietf.org/html/rfc8890 https://tools.ietf.org/html/rfc8890
    - krzyk 6y ago
      My concern is that the benefit is minor, 3% faster web page download? And I wrote that big corporations, because those have millions of users, if users download faster then they can server even more users on smaller amount of hardware. 3% less hardware, that might be big if you are big. And considering it is developed by Google and pushed into Chrome they will get that benefit sooner than others.
  - IfOnlyYouKnew 6y ago
    I, too, like to tell tacky tales of telnet tweaking. Some of them are even true. But to consider those rare instances to be equal or exceeding the value of a significant across-the-board performance increase is ridiculous. As are your attempts at populism: even against specific arguments how the benefits are more meaningful for smaller websites, you repeat the assertion that “the benefits will be reaped by the largest of corporations”. At least you have the decency to immediately contradict yourself.
    - jtbayly 6y ago
      > the value of a significant across-the-board performance increase Extraordinary claims require extraordinary proof.
    - krzyk 6y ago
      Please read section about comments at https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html Thanks
  - jeltz 6y ago
    No, TCP has been bad for a long long time. TCP has never worked on dodgy internet connections. TCP often completely stalls on bad connections.
- otabdeveloper4 6y ago
  I can do better. Get rid of React and the other client-side libraries that reimplement the DOM interface in Javascript except slower and more brittle.
  - steve_adams_86 6y ago
    For what it’s worth, I’ve been profiling front end applications for over a decade, and the only time application bundle size was a real problem was very rare. On the other hand, people writing terrible code usually was the problem, and it would have happened with or without react. I think we’d see faster websites more often if developers had worse computers, or they invested more time in testing in resource constrained environments. I really don’t think react (or similar) is the core problem.
    - RedShift1 6y ago
      This, absolutely. Every developer should get like a Pentium 3 500 MHz and 512 MB of RAM to make their software work.
    - otabdeveloper4 6y ago
      Who said anything about bundle size? There's already a "browser platform framework", it's standard, built into your browser and very fast. Trying to re-implement the browser inside the browser using Javascript is a recipe for disaster. (Indeed: witness the "modern" web.) I get that something more enterprisey-feeling with more knobs for programming in the large is more agreeable to the assembly-line programmer in large IT shops, but if you want your browser apps to act nice you'll have to suck it up and program natively without the overhead of a framework.
- coddle-hark 6y ago
  I don’t like this argument because it’s not like the extra milliseconds are going to make peoples lives more productive/happy/meaningful, even in aggregate. But if you are going to make this argument, one could also argue that it’s better to spend that time looking at loading spinners than looking at Facebook ads.
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).
secondcoming 6y ago
> unfriendly to hackers I think this is quite an important point. If the protocol is so complex such that creating custom implementations is prohibitive then that's an issue, and also perhaps a 'smell'
- p_l 6y ago
  It's easier to create correct HTTP/2 implementation than HTTP 0.9/1.0/1.1 I had enough weekends wrecked by someone thinking they can implement HTTP themselves, only to find out that no, they couldn't, and that was for cases that didn't even hit corners. A netcat "HTTP server" demo is cute, but the power of the computer is that we make tools to make tools that can cover things like HTTP/2 reasonably fast - and much more correct.
  - jart 6y ago
    Could you go more in depth? What project do you work on? What sort of interop issues have you encountered?
    - saurik 6y ago
      FWIW, I have encountered tons of issues in peoples' "this is easy, right?" implementations of 100 Continue (including in some at-the-time major Ruby HTTP servers), non-ASCII encoding in HTTP headers (which has a ton of subtle rules, and just throwing around UTF-8 is not correct), and chunked Transfer-Encoding (though I can't remember what was wrong); further, people often don't even realize HTTP trailers exist at all, which is a bit infuriating :/. (Note, though, that I am still 100% on the side of the anti-HTTP/2 camp in this thread.) The core problem is that somehow people think they can implement a spec without even, you know, reading the spec, which is so far past hubris as to have gone through incompetence into obvious negligence.
    - p_l 6y ago
      Usually the whole 3xx series of return codes, also any 2xx that isn't 200 and 204. If I find someone's "quick and dirty HTTP client library", I generally lose hope that redirects are handled. Anything more complex than that (and there's a lot!) is pipe dream.
pa7x1 6y ago
I think both protocol upgrades are misunderstood: HTTP/2 Besides the performance improvements brought in HTTP/2 via compression of headers and ability to multiplex streams it also enables full-duplex communication (à la WebSockets) [1]. This is used for example in gRPC, making the protocol far more versatile than given credit. [1] No, I'm not talking about Server Push. HTTP/3 HTTP/3 should bring benefits in wireless connections where TCP disconnections are frequent. QUIC handles connection identification so frequent TCP disconnects or even changing IPs would impact much less an HTTP/3 connection. I don't have the benchmarks but I would expect HTTP/3 to shine in this scenario which is bound to be more and more relevant with mobile devices, 5G, etc... In ideal, wired network, conditions HTTP/3 is probably not going to bring any improvement maybe even worse performance considering how much effort must have gone to optimizing TCP. For me, both upgrades have a raison d'être but that doesn't mean that they displace HTTP/1.1 of all use cases. If you don't care about the performance improvements or need full-duplex no need to use HTTP/2, if you are not targeting mobile networks no need for HTTP/3. Luckily protocol negotiation should be quite seamless.
- erinnh 6y ago
  As a general question: why I do have to configure any nginx server that I want to use websockets on to specifically use http 1.1 if 2.0 also has support for them?
  - chrismorgan 6y ago
    WebSockets was defined in a way that was incompatible with HTTP/2. RFC 8441 defines a way of reconciling the two, and explains the nature of the problem in its introduction: https://tools.ietf.org/html/rfc8441#section-1 https://tools.ietf.org/html/rfc8441#section-1. But I don’t believe any browsers has landed support for this yet. (In Chrome it’s been behind a flag for 2½ years with apparently no changes for the last two years. No idea what the hold-up is. https://www.chromestatus.com/feature/6251293127475200 https://www.chromestatus.com/feature/6251293127475200.)
  - pa7x1 6y ago
    To add a bit more information to what the sibling post provides. The original WebSocket handshake is done over HTTP/1.1, there is an RFC specifying how to perform the negotiation also over HTTP/2 connection but its support lacking. On top of that, HTTP/2 itself can do full-duplex communication so it can be used as a replacement of WebSocket, no negotiation or protocol upgrade involved. This capability is rarely used though but is, for example, leveraged by gRPC which is able to do bidirectional streaming [1]. [1] https://grpc.io/docs/what-is-grpc/core-concepts/ https://grpc.io/docs/what-is-grpc/core-concepts/
dinomad 6y ago
You would rarely implement HTTP/1.x yourself. You could, but there are dedicated libraries for that.
- inopinatus 6y ago
  I still find myself connecting with a line-buffered client to GET / and so on, from time to time. Even in 2020 it's still the handiest way to diagnose some issues. I've always appreciated that most IETF protocols are text-oriented with line-buffered commands, and the option to speak the protocol directly in this fashion contributed enormously to my own understanding of SMTP, POP3, IMAP, IRC, NNTP, HTTP, FTP et al, and I always regretted not being to do the same with LDAP, SNMP, or BGP.
  - dinomad 6y ago
    I can support the sentiment, but now when every public facing HTTP endpoint is TLS-protected... That ship has sailed. On internal networks HTTP/1 is not going anywhere any time soon, so there's that.
    - inopinatus 6y ago
      For TLS-wrapped protocols I'll use openssl s_client or ncat or some other simple stdin/out-friendly wrapper. There's no need to abandon line-oriented text-based application protocols just because the next layer down has a binary structure. After all, I'm not crafting TCP segments by hand. I recommend that internal network services use HTTPS, there's plenty of reason not to lower your standards internally.
heipei 6y ago
I actually view HTTP/2 as a great equalizing force for smaller players: It is perfect for "hiding" latency, so you are not forced to use a CDN like Cloudflare just to be closer to your user. Example: I run a service without a CDN, but I only host it on dedicated servers located in Europe. Per-request latency is OKish for users in the US, but my service makes dozens of subrequests to the same origin when loading pages (images, XHR calls). Without HTTP/2, the user-experience for US customers would be abysmal and I'd be forced to reach for a CDN which has a PoP closer to them.
- heipei 6y ago
  https://http2.golang.org/gophertiles?latency=200 https://http2.golang.org/gophertiles?latency=200 and https://http1.golang.org/gophertiles?latency=200 https://http1.golang.org/gophertiles?latency=200 perfectly demonstrate the issue I'd be facing otherwise. 200ms latency from the US West Coast to Europe is realistic, and the number of subresources being requested is also realistic for my application. If you don't believe the latency, try services like these: https://cloudpingtest.com/digital_ocean https://cloudpingtest.com/digital_ocean and https://pingtestlive.com/digitalocean-ping https://pingtestlive.com/digitalocean-ping

by exo762 6y ago

londons_explore 6y ago

> offering huge corporation some millisecond savings millisecond savings for all their users, which adds up to saving man-years every day. It is literally preventing people wasting lifetimes of effort looking at loading spinners. If you can do better, propose it, but don't force other people to waste lifetimes of effort otherwise.

krzyk 6y ago
HTTP 1.1 was good for long, long time. It had major benefits like pure text protocol, that one could use even by doing telnet to webserver (I did that when I needed to debug some pesky issues), starting with HTTP 2.0 it all goes to binary protocol (there is a text one, but almost no browser supports it :( ). And now, on top of that replace years of performance tuning TCP out of the window and use UDP, and invent TCP features on top of UDP. Yes, it is faster (few percent, this is not a 50% increase, it is a mere 3%), but the benefits will be reaped by the largest of corporations. Is it worth it? Maybe for end users (who will get their web page in 485 ms instead of 500ms), but for developers it is not. I was expecting HTTP 3.0 to get us huge benefits, but the numbers that were posted few days ago in hacker news are so underwhelming that I just don't care for it at all. And cost of development is high.
- kxrm 6y ago
  I am not sure I understand your concern, couldn't someone just develop a console app that can traverse the protocol? I am with you in the enjoyment of the simplicity of HTTP/1.1 but I don't agree that this particular concern is large enough to slow adoption.
  - yc12340 6y ago
    It is a complex, stateful (!!) protocol with non-trivial state-machine. A "console app" won't cut it. Even Wireshark might not cut it. Thanks to things like quick start, TLS session tickets and server push you won't understand what are you even looking on 90% of time. When HTTP 1.1 fails, your browser shows you a proper error message. When HTTP 2/3 fails, it is always "a protocol format violation". What violation? Why? Who knows. > I don't agree that this particular concern is large enough to slow adoption Sure thing. Kerberos is still alive and kicking. SMB 1 is built into every appliance. SOAP is the protocol of choice for corporations... Complexity never slows down adoption of <insert name of utter turd technology>, because such technology is generally being pushed down people's throats by someone else. If Google does not push HTTP 3 slower, it's adoption won't slow down. The quality of tech plays no role in that.
    - kxrm 6y ago
      I disagree with the idea that this is being "pushed down people's throats". It's another protocol and nothing has been published stating that HTTP/1.1 support is going anywhere. A protocol format violation notice could tell you what was wrong it just hasn't been developed to the full extent to do so. Give browsers and tools time to develop and be built to properly debug the connection.
- onion2k 6y ago
  Maybe for end users (who will get their web page in 485 ms instead of 500ms), but for developers it is not. If the users see the benefit then the companies that the developers work for will find a new competitive advantage, which benefits the developers (higher profit, better job security, etc). It's impossible for one group to benefit without the other group also benefitting.
- M2Ys4U 6y ago
  >but the benefits will be reaped by the largest of corporations. What isn't? But you're also ignoring the fact that these benefits will also be reaped by end-users - and more by people who have poor connections to the Internet. >Is it worth it? Maybe for end users (who will get their web page in 485 ms instead of 500ms), but for developers it is not. The Internet is for End Users,[0] not for developers. UX >>> DX. [0] https://tools.ietf.org/html/rfc8890 https://tools.ietf.org/html/rfc8890
  - krzyk 6y ago
    My concern is that the benefit is minor, 3% faster web page download? And I wrote that big corporations, because those have millions of users, if users download faster then they can server even more users on smaller amount of hardware. 3% less hardware, that might be big if you are big. And considering it is developed by Google and pushed into Chrome they will get that benefit sooner than others.
- IfOnlyYouKnew 6y ago
  I, too, like to tell tacky tales of telnet tweaking. Some of them are even true. But to consider those rare instances to be equal or exceeding the value of a significant across-the-board performance increase is ridiculous. As are your attempts at populism: even against specific arguments how the benefits are more meaningful for smaller websites, you repeat the assertion that “the benefits will be reaped by the largest of corporations”. At least you have the decency to immediately contradict yourself.
  - jtbayly 6y ago
    > the value of a significant across-the-board performance increase Extraordinary claims require extraordinary proof.
  - krzyk 6y ago
    Please read section about comments at https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html Thanks
- jeltz 6y ago
  No, TCP has been bad for a long long time. TCP has never worked on dodgy internet connections. TCP often completely stalls on bad connections.
otabdeveloper4 6y ago
I can do better. Get rid of React and the other client-side libraries that reimplement the DOM interface in Javascript except slower and more brittle.
- steve_adams_86 6y ago
  For what it’s worth, I’ve been profiling front end applications for over a decade, and the only time application bundle size was a real problem was very rare. On the other hand, people writing terrible code usually was the problem, and it would have happened with or without react. I think we’d see faster websites more often if developers had worse computers, or they invested more time in testing in resource constrained environments. I really don’t think react (or similar) is the core problem.
  - RedShift1 6y ago
    This, absolutely. Every developer should get like a Pentium 3 500 MHz and 512 MB of RAM to make their software work.
  - otabdeveloper4 6y ago
    Who said anything about bundle size? There's already a "browser platform framework", it's standard, built into your browser and very fast. Trying to re-implement the browser inside the browser using Javascript is a recipe for disaster. (Indeed: witness the "modern" web.) I get that something more enterprisey-feeling with more knobs for programming in the large is more agreeable to the assembly-line programmer in large IT shops, but if you want your browser apps to act nice you'll have to suck it up and program natively without the overhead of a framework.
coddle-hark 6y ago
I don’t like this argument because it’s not like the extra milliseconds are going to make peoples lives more productive/happy/meaningful, even in aggregate. But if you are going to make this argument, one could also argue that it’s better to spend that time looking at loading spinners than looking at Facebook ads.

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).

secondcoming 6y ago

> unfriendly to hackers I think this is quite an important point. If the protocol is so complex such that creating custom implementations is prohibitive then that's an issue, and also perhaps a 'smell'

p_l 6y ago
It's easier to create correct HTTP/2 implementation than HTTP 0.9/1.0/1.1 I had enough weekends wrecked by someone thinking they can implement HTTP themselves, only to find out that no, they couldn't, and that was for cases that didn't even hit corners. A netcat "HTTP server" demo is cute, but the power of the computer is that we make tools to make tools that can cover things like HTTP/2 reasonably fast - and much more correct.
- jart 6y ago
  Could you go more in depth? What project do you work on? What sort of interop issues have you encountered?
  - saurik 6y ago
    FWIW, I have encountered tons of issues in peoples' "this is easy, right?" implementations of 100 Continue (including in some at-the-time major Ruby HTTP servers), non-ASCII encoding in HTTP headers (which has a ton of subtle rules, and just throwing around UTF-8 is not correct), and chunked Transfer-Encoding (though I can't remember what was wrong); further, people often don't even realize HTTP trailers exist at all, which is a bit infuriating :/. (Note, though, that I am still 100% on the side of the anti-HTTP/2 camp in this thread.) The core problem is that somehow people think they can implement a spec without even, you know, reading the spec, which is so far past hubris as to have gone through incompetence into obvious negligence.
  - p_l 6y ago
    Usually the whole 3xx series of return codes, also any 2xx that isn't 200 and 204. If I find someone's "quick and dirty HTTP client library", I generally lose hope that redirects are handled. Anything more complex than that (and there's a lot!) is pipe dream.

pa7x1 6y ago

I think both protocol upgrades are misunderstood: HTTP/2 Besides the performance improvements brought in HTTP/2 via compression of headers and ability to multiplex streams it also enables full-duplex communication (à la WebSockets) [1]. This is used for example in gRPC, making the protocol far more versatile than given credit. [1] No, I'm not talking about Server Push. HTTP/3 HTTP/3 should bring benefits in wireless connections where TCP disconnections are frequent. QUIC handles connection identification so frequent TCP disconnects or even changing IPs would impact much less an HTTP/3 connection. I don't have the benchmarks but I would expect HTTP/3 to shine in this scenario which is bound to be more and more relevant with mobile devices, 5G, etc... In ideal, wired network, conditions HTTP/3 is probably not going to bring any improvement maybe even worse performance considering how much effort must have gone to optimizing TCP. For me, both upgrades have a raison d'être but that doesn't mean that they displace HTTP/1.1 of all use cases. If you don't care about the performance improvements or need full-duplex no need to use HTTP/2, if you are not targeting mobile networks no need for HTTP/3. Luckily protocol negotiation should be quite seamless.

erinnh 6y ago
As a general question: why I do have to configure any nginx server that I want to use websockets on to specifically use http 1.1 if 2.0 also has support for them?
- chrismorgan 6y ago
  WebSockets was defined in a way that was incompatible with HTTP/2. RFC 8441 defines a way of reconciling the two, and explains the nature of the problem in its introduction: https://tools.ietf.org/html/rfc8441#section-1 https://tools.ietf.org/html/rfc8441#section-1. But I don’t believe any browsers has landed support for this yet. (In Chrome it’s been behind a flag for 2½ years with apparently no changes for the last two years. No idea what the hold-up is. https://www.chromestatus.com/feature/6251293127475200 https://www.chromestatus.com/feature/6251293127475200.)
- pa7x1 6y ago
  To add a bit more information to what the sibling post provides. The original WebSocket handshake is done over HTTP/1.1, there is an RFC specifying how to perform the negotiation also over HTTP/2 connection but its support lacking. On top of that, HTTP/2 itself can do full-duplex communication so it can be used as a replacement of WebSocket, no negotiation or protocol upgrade involved. This capability is rarely used though but is, for example, leveraged by gRPC which is able to do bidirectional streaming [1]. [1] https://grpc.io/docs/what-is-grpc/core-concepts/ https://grpc.io/docs/what-is-grpc/core-concepts/

dinomad 6y ago

You would rarely implement HTTP/1.x yourself. You could, but there are dedicated libraries for that.

inopinatus 6y ago
I still find myself connecting with a line-buffered client to GET / and so on, from time to time. Even in 2020 it's still the handiest way to diagnose some issues. I've always appreciated that most IETF protocols are text-oriented with line-buffered commands, and the option to speak the protocol directly in this fashion contributed enormously to my own understanding of SMTP, POP3, IMAP, IRC, NNTP, HTTP, FTP et al, and I always regretted not being to do the same with LDAP, SNMP, or BGP.
- dinomad 6y ago
  I can support the sentiment, but now when every public facing HTTP endpoint is TLS-protected... That ship has sailed. On internal networks HTTP/1 is not going anywhere any time soon, so there's that.
  - inopinatus 6y ago
    For TLS-wrapped protocols I'll use openssl s_client or ncat or some other simple stdin/out-friendly wrapper. There's no need to abandon line-oriented text-based application protocols just because the next layer down has a binary structure. After all, I'm not crafting TCP segments by hand. I recommend that internal network services use HTTPS, there's plenty of reason not to lower your standards internally.

heipei 6y ago

I actually view HTTP/2 as a great equalizing force for smaller players: It is perfect for "hiding" latency, so you are not forced to use a CDN like Cloudflare just to be closer to your user. Example: I run a service without a CDN, but I only host it on dedicated servers located in Europe. Per-request latency is OKish for users in the US, but my service makes dozens of subrequests to the same origin when loading pages (images, XHR calls). Without HTTP/2, the user-experience for US customers would be abysmal and I'd be forced to reach for a CDN which has a PoP closer to them.

heipei 6y ago
https://http2.golang.org/gophertiles?latency=200 https://http2.golang.org/gophertiles?latency=200 and https://http1.golang.org/gophertiles?latency=200 https://http1.golang.org/gophertiles?latency=200 perfectly demonstrate the issue I'd be facing otherwise. 200ms latency from the US West Coast to Europe is realistic, and the number of subresources being requested is also realistic for my application. If you don't believe the latency, try services like these: https://cloudpingtest.com/digital_ocean https://cloudpingtest.com/digital_ocean and https://pingtestlive.com/digitalocean-ping https://pingtestlive.com/digitalocean-ping