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

HTTP/2 Is Done

mnot.net

Post reply on HN
Print view View original

101–110 of 144 posts

Re: HTTP/2 Is Done

#101

Post by jimktrains2 »

andrewstuart2 wrote: post #4
lazyloop wrote: post #3

HTTP/2 is a bad protocol, that much is clear by now. Luckily most of us won't have to deal with it, because it will be deployed merely as an optimization, with a new generation of reverse-proxy servers, like H2O. https://github.com/h2o/h2o

Care to at least explain why you think it's a bad protocol?

Because it doesn't solve any problems except page loading speed. There are other things that people care about and the added complexity of implementing Layer 4 in Layer 7 make it even more of a monstrosity.

I put this in another comment in the above:

* 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

Re: HTTP/2 Is Done

#102

Post by tveita »

megaman821 wrote: post #29
tptacek wrote: post #26

Earlier quoted context omitted.

"Standardize authentication"?

Well Basic Auth exists now, but it is unusable for most sites due to several well-documented shortcomings. Surely something could be done to improve upon it.

You can add new authentication methods by defining the format of the authorization/authentication headers. OAuth 2 does it. The only thing you need is buy-in from application authors.

Re: HTTP/2 Is Done

#103

Post by mattmanser »

josteink wrote: post #93
mattmanser wrote: post #64

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…

You're missing the point. For all of them ut doesn't matter if my consumer website serves multiple assets.

That's what I'm talking about.

Re: HTTP/2 Is Done

#104

Post by tptacek »

megaman821 wrote: post #29
tptacek wrote: post #26

Earlier quoted context omitted.

"Standardize authentication"?

Well Basic Auth exists now, but it is unusable for most sites due to several well-documented shortcomings. Surely something could be done to improve upon it.

The most important shortcoming of basic auth is the idea of building it into the protocol to begin with. Session authentication is superior to basic auth.

Re: HTTP/2 Is Done

#105

Post by patrickmcmanus »

megaman821 wrote: post #24
andrewstuart2 wrote: post #4

Earlier quoted context omitted.

Care to at least explain why you think it's a bad protocol?

It is not a bad protocol for what is in there, it is bad for what is not. It seems like it was built for the big players to eek out 5% more performance. How about the average website? What is in there help standardize authentication? What is in there to help protect privacy? In the end it looks more HTTP 1.2, with header compression being the only new feature. The rest of what makes up HTTP 2 is basically implementin…

arbitrary levels of prioritized multiplexing within a functioning congestion control context is the killer feature of http/2.

header compression exists merely to enable that as an implementation detail.

Re: HTTP/2 Is Done

#106

Post by megaman821 »

tveita wrote: post #102
megaman821 wrote: post #29

Earlier quoted context omitted.

Well Basic Auth exists now, but it is unusable for most sites due to several well-documented shortcomings. Surely something could be done to improve upon it.

You can add new authentication methods by defining the format of the authorization/authentication headers. OAuth 2 does it. The only thing you need is buy-in from application authors.

This is mostly true but browsers treat Basic Auth special. To use Authorization Bearer headers you have to use JavaScript and perhaps localstorage. When using Basic Auth the browser caches your credentials and allows you to be authenticated without cookies and without JavaScript code. The only way you can use OAuth header authorization today is with JavaScript apps, Basic Auth works with normal server side apps.

Re: HTTP/2 Is Done

#107

Post by exelius »

ddalex_ro wrote: post #66
byuu wrote: 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…

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

Not true! Text parsing is a pain in the ass; give me a well-documented binary protocol any day. On the upside, binary protocols tend to force good documentation. HTTP/1.1 is far from simple; every browser supports a slightly different implementation and the server is expected to serve to all of them. But a binary protocol is not any more difficult than a text-based protocol for someone with a decent knowledge of CS. If you don't have a decent knowledge of CS, you probably shouldn't be writing code at the protocol level.

Besides, who in their right mind outputs directly to ANY protocol these days? Unless you're building a web server, you should be doing it through an abstraction layer because it's a proper architecture practice. Once abstraction layers are built for all of the major languages (which I'm willing to bet has already happened) it will become a non-issue.

Re: HTTP/2 Is Done

#108

Post by jimktrains2 »

zackelan wrote: post #28
megaman821 wrote: post #24

Earlier quoted context omitted.

It is not a bad protocol for what is in there, it is bad for what is not. It seems like it was built for the big players to eek out 5% more performance. How about the average website? What is in there help standardize authentication? What is in there to help protect privacy? In the end it looks more HTTP 1.2, with header compression being the only new feature. The rest of what makes up HTTP 2 is basically implementin…

> help standardize authentication > help protect privacy I think this is sort of answered by the headline - "HTTP/2 is done ". If they had succumbed to the second-system effect and added every bell and whistle that every HTTP user would ever want, there would be an endless period of bikeshedding and it would be years before you could even call the spec "done". They seem to have taken a more conservative approach - ch…

Or they could have solved actual problems people have like the lacking of privacy features and the problems with HTTP Authentication currently.

Re: HTTP/2 Is Done

#109

Post by viraptor »

byuu wrote: post #77
nyir wrote: post #68

Earlier quoted context omitted.

I haven't looked more into that, but wouldn't it also be viable now to start HTTP/1.2 with e.g. a more restrictive header grammar, restricting all existing features to what's actually used, at least on the server side? Clients with 1.1 support would keep working, but future clients would be simplified.

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…

> If browsers want to warn that it's not encrypted, fine. So long as they don't go into ridiculous hysteria levels like they do now with self-signed certs.

I don't believe they can do anything apart from what happens now. Imagine someone manages to redirect your traffic. You were talking to some website which used known certificate, but this time you got a self-signed one. The browser has two options essentially:

- continue the connection - in this case you just handed over your session cookie, the person on the other side can act as you on that website

- go into "ridiculous hysteria levels" and tell you that the cert presented by the server is not trusted - so do what browsers do right now

There's really no situation where the first option should be allowed. How option 2 is implemented is the interesting detail.

Re: HTTP/2 Is Done

#110

Post by TylerE »

bhouston wrote: post #100
TylerE wrote: post #96

Earlier quoted context omitted.

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.

There is support for extensions, but they're, well, extensions. The only thing the protocol specifies is that a compliant implementation must pass-through unchanged any block it doesn't understand.

Compare with HTTP/1.1 where for instance the entire content negotiation mechanism is optional and clients need to be able to deal with it not being available.

Post reply on HN