Live data from Hacker News

HTTP/2 Is Done

mnot.net

91–100 of 144 posts

Re: HTTP/2 Is Done

#91
post #77

Earlier quoted context omitted.

That would be absolutely lovely. Since we're not viewing headers manually on 80x25 terminals anymore, we could do away with multi-line header values. That alone would drop off most of the complexity. (Being perfectly honest, even though it's part of the standard, you don't have to parse them now, anyway. I don't, and I've never had anyone complain to me about the site not working. Nothing mainstream sends them for th…

I am with you up to letting people use unencrypted HTTP. I assume people in this can use telnet instead of ssh because it is simpler. No, browsers should drop support for unencrypted HTTP soon after Let's Encrypt goes live.

> browsers should drop support for unencrypted HTTP soon after Let's Encrypt goes live.

To the people who keep insisting everything needs encryption: No it doesn't. Fuck off!

You don't see me forcing PGP on on your email, do you? No? Fine, then let us non-weirdoes keep using plain HTTP where we want it, where we have determined that it is a good fit for our needs.

Besides, this is purely a theoretical concern because a browser which drops support for plain HTTP wont have any user-base as soon people discover that 95% of the internet will broken when using that browser.

Re: HTTP/2 Is Done

#92
post #65

Earlier quoted context omitted.

> May nobody else have to suffer through writing an interoperable HTTP/1.1 parser! Yes, now it'll be much easier than parsing plain-text. Now they just have to write a TLS stack (several key exchange algorithms; block ciphers; stream ciphers; and data integrity algorithms); then implement the new HPACK compression; then finally a new parser for the HTTP/2 headers themselves. Now instead of taking maybe one day to wri…

And the lack in simplicity is why it will fail. People are good with dealing with a small number of simple things that can be stacked together. Throw in a human-readable data stream, and you're set to understand and use a stack of simple programs. People are not good with dealing with a single monstrous object of unfathomable proportions, they will try to break it down in things they understand. If the thing is too c…

I'm really confused by comments like these. Are you somebody who implements low-level network protocols?

I've written parsers and generators for plenty of binary protocols. It's actually really not that bad - you just need slightly different tooling. Yes, if somebody else hasn't written those it takes a bit longer because you have to do that yourself, but you save a lot of time because it's far easier to parse than text. And guess what - people have already written plenty of tooling for HTTP/2 already... And HTTP/2 is fairly straightforward as protocols go (you wouldn't believe the crazy proprietary control protocols around the place - trust me, HTTP/2 is not at all bad)

The 'downfall' of HTTP/2 is also a real long shot - most people are already browsing in browsers that support it, and for many web site owners, using it is literally adding two lines to an nginx configuration file...

Re: HTTP/2 Is Done

#93
post #49

Earlier quoted context omitted.

The real problem, I think, will be moving to "idiomatic" HTTP2-centric design (lots of little resources, relying on parallel chunked delivery and server-suggested retrieval) while still keeping HTTP/1.1 clients fast. I'm betting there will come a polyfill to make HTTP/2 servers able to deliver content to HTTP/1.1-but-HTML5 web browsers in an HTTP/2-idiomatic way—perhaps, for example, delivering the originally-request…

Now that all of the browsers have moved to an auto update model and the only ones that haven't are on mobiles that have short lifespans, that's really only going to be important to the big players for about a year or two. Or maybe I'm overly optimistic!

Think all software written for all devices involving every single embedded thingie with a webclient reporting in or polling data everywhere: Every ATM, every POS device, every IOT-device made yet and everyone to be made in the future. Every little gadget with a network stack ever made.

And you're telling me all of those will have an updated HTTP-stack within 2 years?

You're not being "overly optimistic", you're being tragically unrealistic.

Like every other published internet-standard, HTTP/1.0 and HTTP/1.1 will be here until the end of the internet. Sadly the clusterfuck that is HTTP/2.0 will too now.

The people talking about HTTP/3.0 already really seems to have missed this bit. (They're talking about 3.0 because HTTP/2.0 didn't really solve the problems we have with HTTP/1.1, but nevermind that, Google steam-rolled this one through and we want to be trendy)

The question is now: How many HTTP-stacks do you want to support? Is 2 OK? 3? 4? When do you say enough is enough?

Re: HTTP/2 Is Done

#94
post #76

Earlier quoted context omitted.

Then we clearly have different definition of "application". For me, an web application runs in the browser, not merely exposes an API over HTTP that can be used by HTML from a browser.

You have a very narrow definition of an application then.

Please elaborate.

Re: HTTP/2 Is Done

#95
post #65

Earlier quoted context omitted.

> May nobody else have to suffer through writing an interoperable HTTP/1.1 parser! Yes, now it'll be much easier than parsing plain-text. Now they just have to write a TLS stack (several key exchange algorithms; block ciphers; stream ciphers; and data integrity algorithms); then implement the new HPACK compression; then finally a new parser for the HTTP/2 headers themselves. Now instead of taking maybe one day to wri…

Have you tried writing anything more than a very simple HTTP/1.1 parser/server? It's actually not as easy as it seems at first - edge cases everywhere, different user agents doing subtly different things, etc. etc. Your argument is invalid in my opinion. HTTP/1.1 is not simple to implement to any decent level of completeness and correctness, and HTTP/2 does fix a fair few things. Anyway, there are already plenty of g…

So won't HTTP/2 have these edge cases also?

Re: HTTP/2 Is Done

#96

Earlier quoted context omitted.

Have you tried writing anything more than a very simple HTTP/1.1 parser/server? It's actually not as easy as it seems at first - edge cases everywhere, different user agents doing subtly different things, etc. etc. Your argument is invalid in my opinion. HTTP/1.1 is not simple to implement to any decent level of completeness and correctness, and HTTP/2 does fix a fair few things. Anyway, there are already plenty of g…

So won't HTTP/2 have these edge cases also?

Essentially, no.

HTTP/1.1 contains tons of optional features. Practially no two implementations support the same set.

HTTP/2 is all 100% mandatory. Any compliant HTTP/2 implementation will support an EXACT set of known features.

Re: HTTP/2 Is Done

#97

Earlier quoted context omitted.

Now that all of the browsers have moved to an auto update model and the only ones that haven't are on mobiles that have short lifespans, that's really only going to be important to the big players for about a year or two. Or maybe I'm overly optimistic!

Think all software written for all devices involving every single embedded thingie with a webclient reporting in or polling data everywhere: Every ATM, every POS device, every IOT-device made yet and everyone to be made in the future. Every little gadget with a network stack ever made. And you're telling me all of those will have an updated HTTP-stack within 2 years? You're not being "overly optimistic", you're being…

> The people talking about HTTP/3.0 already really seems to have missed this bit. (They're talking about 3.0 because HTTP/2.0 didn't really solve the problems we have with HTTP/1.1, but nevermind that, Google steam-rolled this one through and we want to be trendy)

Exactly! There are more important problems to solve, page load time isn't one of them. My list includes:

* Better authentication

* More secure caching

* Improved ability to download large files

* Better methods to find alternate downloads locations

* Making each request contain less information about the sender

* Improved Metadata

I brain-dump a bit here: https://github.com/jimktrains/http_ng

EDIT: Formatting

Re: HTTP/2 Is Done

#98
post #76

Earlier quoted context omitted.

Then we clearly have different definition of "application". For me, an web application runs in the browser, not merely exposes an API over HTTP that can be used by HTML from a browser.

You have a very narrow definition of an application then.

Absolutely. I'm sick and tired of idiot developers fucking up the web with their bullshit "apps" which are slow, crash all the time, and break everything.

I've worked on more "web apps" than I can count and the reality is, only 2 of them were legitimate use cases for a pure JS solution. And we gain nothing from it. I've just spent all morning debugging an issue with a complicated angular directive (and not for the first time) that would have been a few lines of jquery a couple of years ago. Probably because a bored dev wanted to play with a new toy.

As you imply, we were writing sophisticated web apps long before AJAX was popularised and those apps were way more reliable and predictable than what we have now, and they worked in Lynx if you wanted.

Re: HTTP/2 Is Done

#99
post #96

Earlier quoted context omitted.

So won't HTTP/2 have these edge cases also?

Essentially, no. HTTP/1.1 contains tons of optional features. Practially no two implementations support the same set. HTTP/2 is all 100% mandatory. Any compliant HTTP/2 implementation will support an EXACT set of known features.

Won't that create the same problems as XML and XHTML where full compliance is/was mandatory -- and the reality turned out to be different?

Re: HTTP/2 Is Done

#100
post #96

Earlier quoted context omitted.

So won't HTTP/2 have these edge cases also?

Essentially, no. HTTP/1.1 contains tons of optional features. Practially no two implementations support the same set. HTTP/2 is all 100% mandatory. Any compliant HTTP/2 implementation will support an EXACT set of known features.

> HTTP/2 is all 100% mandatory. Any compliant HTTP/2 implementation will support an EXACT set of known features.

But over the next couple of years, won't people come up with new ideas and add them as optional extensions? How is that handled?

I suspect some of these optional extensions will be really useful in special cases such as support for LZMA/LZHAM compression in addition to just gzip.

Post reply on HN