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

61–70 of 144 posts

Re: HTTP/2 Is Done

#61

Post by youngtaff »

tokyo1000 wrote: post #19
jgrahamc wrote: post #7

[placeholder for commentary about how HTTP/2 is a bad protocol because it's binary and everything could have been fixed in a text protocol follow by ad nauseum repetition of all the same old arguments]

The fact that there's so much disagreement and discontent surrounding this should concern everyone involved. Trade-offs are being made that may benefit some people and organizations, but these trade-offs are also causing significant problems for others. While there has always been some degree of disagreement regarding technological matters, I think we're really seeing a lot more of it these days, especially when it c…

Is there "so much disagreement and discontent"?

There's a few high profile critics e.g. PHK, who puts his points as an eloquent rant which of course we as a community tend to love but the reality is HTTP/2 is going to get rollout by companies who've tested it and seen the benefits i.e. not just Google.

Re: HTTP/2 Is Done

#62

Post by exogen »

hueving wrote: post #52
bgentry wrote: post #33

Earlier quoted context omitted.

If anyone wants to learn more about optimizing for HTTP/2, unwinding HTTP/1.1 hacks, and strategies to optimize for both versions at the same time, Ilya Grigorik's "High Performance Browser Networking" is an excellent resource: http://chimera.labs.oreilly.com/books/1230000000545/ch13.htm...

If it requires a book to optimize for HTTP2, doesn't that counter your comment's parent's point? It's supposed to be simple.

One can write a book about literally anything. But besides that, it already "required" a book – at least two of them in fact, both published before Google even announced SPDY: "High Performance Web Sites" [1] in 2007 and its sequel "Even Faster Web Sites" [2] in 2009, both by Steve Souders.

What are they about? Essentially, optimizing your HTTP responses for the ways in which actual web browsers make HTTP requests. Any web performance analysis tool worth using (like YSlow and PageSpeed – both of which Steve Souders was involved in btw) recommended the practices outlined in those books.

So, no. I don't think a new book with updated practices says anything about the protocol. The optimization tips from this book will simply become widespread common knowledge the same way they did in the past.

[1] http://shop.oreilly.com/product/9780596529307.do [2] http://shop.oreilly.com/product/9780596522315.do

Re: HTTP/2 Is Done

#63

Post by theallan »

Does anyone have any information about HTTP/2 development in Apache? Searching the bug list I don't immediately see anything and the only thing I can find from a Google search is a mailing list entry with someone asking about http/2 development and being told that it isn't really being worked on [1]

[1] http://mail-archives.apache.org/mod_mbox/httpd-dev/201408.mb...

Re: HTTP/2 Is Done

#64

Post by mattmanser »

derefr wrote: post #49
bgentry wrote: post #16

It's time to begin the long process of unwinding all the hacks that we've built to make HTTP/1.1 fast. No more concatenation of static assets, no more domain sharding. The future looks more like this, as the default, with no special effort required: https://http2.golang.org/gophertiles May nobody else have to suffer through writing an interoperable HTTP/1.1 parser!

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!

Re: HTTP/2 Is Done

#65

Post by byuu »

bgentry wrote: post #16

It's time to begin the long process of unwinding all the hacks that we've built to make HTTP/1.1 fast. No more concatenation of static assets, no more domain sharding. The future looks more like this, as the default, with no special effort required: https://http2.golang.org/gophertiles May nobody else have to suffer through writing an interoperable HTTP/1.1 parser!

> 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 write an HTTP/1.1 server, it'll only take a single engineer several years to write an HTTP/2 server (and one mistake will undermine all of its attempts at security.)

If you are going to say, "well use someone else's TLS/HPACK/etc library!", then I'll say the same, "use someone else's HTTP/1.1 header parsing library!"

HTTP/2 may turn out to be great for a lot of things. But making things easier/simpler to program is certainly not one of them. This is a massive step back in terms of simplicity.

Re: HTTP/2 Is Done

#66

Post by ddalex_ro »

byuu wrote: post #65
bgentry wrote: post #16

It's time to begin the long process of unwinding all the hacks that we've built to make HTTP/1.1 fast. No more concatenation of static assets, no more domain sharding. The future looks more like this, as the default, with no special effort required: https://http2.golang.org/gophertiles May nobody else have to suffer through writing an interoperable HTTP/1.1 parser!

> 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 complex, with too many inputs, too many outputs and too many states, this is a recipe for confusion. This is why overly complicated things always fail in face of simple things.

One could argue that FTP/SFTP was just as good as transferring bytes over network, but HTTP/1.0 won because it was simpler.

HTTP/2 was written to tickle the egos of its developers, following the principle - it is hard to write, it is hard to read. And its downfall is going to come from this problem.

Re: HTTP/2 Is Done

#67

Post by stephenr »

blueskin_ wrote: post #57
ecthiender wrote: post #32

Earlier quoted context omitted.

Excuse my ignorance, but how can I do session management without using cookies? I tried searching on the net, but it doesn't seem to give any concrete/valid results. Can you give me any pointers? Edit: I do use OAuth2.0 on my services and use Mozilla Persona to manage user logins, but I am not clear how can I keep sessions between requests if I don't use cookies.

Theoretically, we could move to a private key based system, where your browser encrypts/signs with a private key for each site, but there's neither the will to do it, nor the means to make it simple for the room temperature IQs. Shame, as the privacy and security benefits would be amazing.

This could be done today with TLS Client Certificates. There is already browser support (through either or the MS alternative, which is an API rather than an element, I believe) for creating a private/public key pair, and sending the public key to the server.

Unfortunately it's not fantastically simple to move to a new device (particularly not a mobile device where client certs are even harder to install)

Re: HTTP/2 Is Done

#68

Post by nyir »

byuu wrote: post #65
bgentry wrote: post #16

It's time to begin the long process of unwinding all the hacks that we've built to make HTTP/1.1 fast. No more concatenation of static assets, no more domain sharding. The future looks more like this, as the default, with no special effort required: https://http2.golang.org/gophertiles May nobody else have to suffer through writing an interoperable HTTP/1.1 parser!

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

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.

Re: HTTP/2 Is Done

#69

Post by iopq »

byuu wrote: post #65
bgentry wrote: post #16

It's time to begin the long process of unwinding all the hacks that we've built to make HTTP/1.1 fast. No more concatenation of static assets, no more domain sharding. The future looks more like this, as the default, with no special effort required: https://http2.golang.org/gophertiles May nobody else have to suffer through writing an interoperable HTTP/1.1 parser!

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

HTTP/2 is easier to parse than HTTP/1.1 because there's less edge cases

Also a bonus: no more "Referer" (sic)

Re: HTTP/2 Is Done

#70

Post by EugeneOZ »

bgentry wrote: post #16

It's time to begin the long process of unwinding all the hacks that we've built to make HTTP/1.1 fast. No more concatenation of static assets, no more domain sharding. The future looks more like this, as the default, with no special effort required: https://http2.golang.org/gophertiles May nobody else have to suffer through writing an interoperable HTTP/1.1 parser!

nginx doesn't support http2, apache too.. So maybe it's time to make some efforts to implement it on servers first. Maybe make some donations to apache, nginx dev. teams to speed up this process.
Post reply on HN