Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

HTTP/1 should die; HTTP/2 can do everything HTTP/1 could, only faster

medium.com

Post reply on HN
Print view View original

21–30 of 62 posts

Re: HTTP/1 should die; HTTP/2 can do everything HTTP/1 could, only faster

#21

Post by pdpi »

crankylinuxuser wrote: post #12
mankyd wrote: post #5

One important difference: HTTP/2 requires* encryption. This makes getting up and running for local development and small deployments more difficult. * https://http2.github.io/faq/#does-http2-require-encryption "[...] currently no browser supports HTTP/2 unencrypted."

I'm guessing they're not carving out a niche for self-signed certs? I think that would have been a fair balance, of setting a "this is a self-signed cert" instead of the current "YoUr WeBsIte IS UNSECURED" (which isn't actually true). Accepting and indicating self signed would also be handy in Tor's onion sites, since the only companies that will issue certs require EV2 and all your info and a pile of money. And Onio…

The only people who ever see the “this is insecure” page when it is actually a perfectly fine self-signed certificate know better.

If you special-case self signed certificates, at it looks any less threatening, you will eventually have that page presented to unsuspecting victims.

Re: HTTP/1 should die; HTTP/2 can do everything HTTP/1 could, only faster

#22

Post by eeeeeeeeeeeee »

skywhopper wrote: post #16

Actually, no. HTTP/2 cannot be easily read or written by a human with a telnet or s_client connection without some additional tools. It also can't be supported by a lot of old software without some additional layer of indirection. This may or may not be important to you, but it is a thing that HTTP/2 cannot do.

I'm not sure why you're being downvoted. The financial/resource burden of learning new technologies should be considered and weighed against the advantages it delivers over the old technology.

Re: HTTP/1 should die; HTTP/2 can do everything HTTP/1 could, only faster

#23

Post by nindalf »

pgjones wrote: post #10
the_other_guy wrote: post #9

pathetic that you only make people pay attention using clickbaity and angry titles

I think my articles in the past have been too dull; I think people would like to read something interesting and entertaining so I'm trying to improve in this regard. Was the article a good read or did the title put you off?

Folks generally click baity articles more, but are unhappy about the fact they were baited into clicking a low quality article. It's a dilemma - do you want people to be happy or do you want more readers?

Feedback on the article - haven't you chosen a pathological case of a single click triggering 20 API calls that don't depend on each other? Wouldn't it be simpler to batch these calls on the server?

Re: HTTP/1 should die; HTTP/2 can do everything HTTP/1 could, only faster

#25

Post by berry_sortoro »

the_other_guy wrote: post #9

pathetic that you only make people pay attention using clickbaity and angry titles

Pathetic how offended you get because someone over this supposedly "angry and clickbaity" title. He used the word die. So what? Would you make the same comment if it would be about flash? I do not perceive this as angry at all and not even really click-bait. There are so many actually good examples for true clickbait, this is not one of them.

Re: HTTP/1 should die; HTTP/2 can do everything HTTP/1 could, only faster

#26

Post by acdha »

skywhopper wrote: post #16

Actually, no. HTTP/2 cannot be easily read or written by a human with a telnet or s_client connection without some additional tools. It also can't be supported by a lot of old software without some additional layer of indirection. This may or may not be important to you, but it is a thing that HTTP/2 cannot do.

> HTTP/2 cannot be easily read or written by a human with a telnet or s_client connection without some additional tools

This is, of course, why we also don't use chunked encoding and compression with HTTP 1 rather than writing better tools. I mean, you even have the example in that sentence about how the solution for using TLS was not to say “it doesn't work with telnet” but to use s_client, ncat, socat, etc.

> It also can't be supported by a lot of old software without some additional layer of indirection

This part is true but it's also the classic legacy computing problem: old software which cannot be upgraded will increasingly have security and compatibility issues which favor putting it behind a proxy anyway. This should factor into the cost of choosing not to maintain those systems rather holding back the future.

Re: HTTP/1 should die; HTTP/2 can do everything HTTP/1 could, only faster

#27

Post by rqs »

I rather believe HTTP/2 will die when HTTP/3 is available.

After all HTTP/1 is very simple to implement and already widely used and optimized. It is usable for most of cases. Plus, maybe in the future, CDN can serve HTTP/2 to client while use HTTP/1 to read the source.

And currently web browsers still need to send Upgrade request in HTTP/1 to know whether or not a unknown HTTP server supports HTTP/2. I guess this will still be true after HTTP/3 comes out (alt-svc).

Re: HTTP/1 should die; HTTP/2 can do everything HTTP/1 could, only faster

#28

Post by kevin_b_er »

mankyd wrote: post #5

One important difference: HTTP/2 requires* encryption. This makes getting up and running for local development and small deployments more difficult. * https://http2.github.io/faq/#does-http2-require-encryption "[...] currently no browser supports HTTP/2 unencrypted."

As such, we know this statement to be false: "With WebSocket HTTP/2 support there is nothing that HTTP/1.1 can do that HTTP/2 cannot"

Re: HTTP/1 should die; HTTP/2 can do everything HTTP/1 could, only faster

#29

Post by pmalynin »

rqs wrote: post #27

I rather believe HTTP/2 will die when HTTP/3 is available. After all HTTP/1 is very simple to implement and already widely used and optimized. It is usable for most of cases. Plus, maybe in the future, CDN can serve HTTP/2 to client while use HTTP/1 to read the source. And currently web browsers still need to send Upgrade request in HTTP/1 to know whether or not a unknown HTTP server supports HTTP/2. I guess this wil…

Actually HTTP2 upgrade isn’t done with an “Upgrade:” request, but rather with TLS protocol negotiation.
Post reply on HN