[drderidder]

I got a copy of Paul-Henning Kamp's critique "HTTP/2.0 - The IETF is Phoning It In" off the ACM website before the link went dead. Here's a bit of what he said about it:

"Some will expect a major update to the world’s most popular protocol to be a technical masterpiece and textbook example for future students of protocol design. Some will expect that a protocol designed during the Snowden revelations will improve their privacy. Others will more cynically suspect the opposite. There may be a general assumption of "faster." Many will probably also assume it is "greener." And some of us are jaded enough to see the "2.0" and mutter "Uh-oh, Second Systems Syndrome."

The cheat sheet answers are: no, no, probably not, maybe, no and yes.

If that sounds underwhelming, it’s because it is.

HTTP/2.0 is not a technical masterpiece. It has layering violations, inconsistencies, needless complexity, bad compromises, misses a lot of ripe opportunities, etc. I would flunk students in my (hypothetical) protocol design class if they submitted it. HTTP/2.0 also does not improve your privacy. Wrapping HTTP/2.0 in SSL/TLS may or may not improve your privacy, as would wrapping HTTP/1.1 or any other protocol in SSL/TLS. But HTTP/2.0 itself does nothing to improve your privacy. This is almost triply ironic, because the major drags on HTTP are the cookies, which are such a major privacy problem, that the EU has legislated a notice requirement for them. HTTP/2.0 could have done away with cookies, replacing them instead with a client controlled session identifier. That would put users squarely in charge of when they want to be tracked and when they don't want to—a major improvement in privacy. It would also save bandwidth and packets. But the proposed protocol does not do this.

[He goes on to tear a strip off the IETF and the politics behind HTTP/2.0 ...]

[magicalist]

That critique was a poor one. In fact, what you quoted was the meat of it, with little to back up the hyperbole, except for the argument that we shouldn't have all connections encrypted because that will make the NSA work harder to break all encryption. Which is not a good argument.

The discussion on it covered it pretty well: https://news.ycombinator.com/item?id=8850059

edit: it's still in google cache if anyone else wants to read it for themselves: https://webcache.googleusercontent.com/search?q=cache:3i6EwF...

[runeks]

> This is almost triply ironic, because the major drags on HTTP are the cookies, which are such a major privacy problem, that the EU has legislated a notice requirement for them.

Which, of course, is useless, since any browser supports turning off cookies.

As an EU citizen, my experience of this regulation is simply that I have to click "OK" to accept cookies on all the EU sites I visit.

I apologize if this comes off as a rant, but it really is annoying to constantly be presented with "This site uses cookies. Continue?" when I visit a site. :)

[pgsandstrom]

Agreed, it is completely useless. I have never heard of anyone benefiting from this the slightest. A side effect could have been that people actually stopped and learned what cookies was, but as I've asked my non-technical friends, no one has bothered to do this. I can't say I blame them.

[Kurtz79]

My experience is the same, with an added facepalm everytime I see it.

It is a EU thing then ? It appears or not depending on the origin ip address of the request ?

[jorisw]

Yes, it is law in various EU countries that requires websites to ask permission to store cookies. However, now that the leglislators have seen the effect and have educated themselves some more, the law is already being effectively retracted, at least in my country (NL).

[jimktrains2]

Which is why, as a tech community, we should have attempted to come up with a better solution. A session identifier controlled by the client (Say, just a UUID and can store no data from the server) and with the associated UI to cleaning "logout" or "reset" a session with a website, may have alleviated privacy concerns without breaking the functionality we originally were looking to add to HTTP.

Yes, this would not have been able to be rolled out to everyone immediately, but neither is any other addition to JS, HTTP, HTML, CSS, &c. We should help build the future, not simply accommodate the past all the time.

[tracker1]

Considering (relative to now) cookies were added really early on... it would have made sense to have a user/browser token that was only available to a single site, with a reset option.

Another thing that's a little irksome is that nobody uses http auth, because there's no easy logout option.

I will say I do like parts of http/2 being there... I think that dnssec + tls should have been part of the official mix. At the very least CA pricing has fallen into a reasonable range (about $10/month) for wildcard certs. Another thing that took too long is SNI.

Overall though, I think people have gotten pretty spoiled when it comes to technology (myself included)... OMG it takes a whole second and a half between clicking login and being able to see my bank statement. I remember when it was 15-seconds... I think everyone should experience a modem ANSI interface at 9600bps... (not just because I still like BBSes and ANSI art).

[jimktrains2]

I 100% agree with you on the auth part. Mutual auth via something like SRP built into the browser would be a huge boon to building web sites that don't have to handle the plain-text password. Some nice chrome on that, or even an interface with HTML (<form method="mutal-auth-login"> <form method="mutal-auth-logout"> or something) would be super nice.

> OMG it takes a whole second and a half between clicking login and being able to see my bank statement. I remember when it was 15-seconds

What's worse is that people seem to get offended when you say "I have a crappy computer and a crappy connection, this is too bloated". I actually started running noscript soley to block analytics and ads that causing page rendering to delay for 10+s. I had the page. It was all there, but the browser had to wait for all resources before it'd do a full render. All of that immediately stopped with noscript.

[wmf]

HTTP/2 may actually help PHK get what he wants sooner. Proposing to make major syntax and semantic changes would have turned HTTP/2 into an extremely contentious 10-year project. Splitting that into more manageable chunks (syntax in HTTP/2, semantics in HTTP/3), combined with the iterative process that was used to evolve SPDY into HTTP/2, may be more tractable.

Of course, no process will will help you if everyone disagrees with your proposals.

[josteink]

> Splitting that into more manageable chunks (syntax in HTTP/2, semantics in HTTP/3), combined with the iterative process

Sounds great!

Just one question: How many versions of the (now flabagasteringly complex) HTTP-protocol will I need to support in my application and libraries? Because as we all know, once deployed on the internet, something will never be updated and will need to be supported forever, meaning you can never obsolete that HTTP/1.1 and /2.0 code.

HTTP/1.1 was a fantastic protocol in that it survived for almost 2 decades unchanged. Here we have HTTP/2.0 and people are already talking about what we will need to add to HTTP/3.0.

If HTTP is going to end up being the new MSIE, we can only blame ourselves because we allowed Google to use its dominance to push a protocol the internet didn't need.

[enneff]

Whatever PHK wants it to be, HTTP/2 is a great step forward from where we are today. Check this out: https://http2.golang.org/gophertiles

This is going to make the web so much faster, particular on mobile devices.

[jimktrains2]

> Whatever PHK wants it to be, HTTP/2 is a great step forward from where we are today.

A hugely bloated, binary protocol is better than the simple, text-based on we have today? I greatly disagree. HTTP/1.1 could use an update, but HTTP/2 was not the answer.

[MichaelGG]

I wonder if anyone complaining about binary formats has ever written a high performance parser.

Particularly, HTTP's text format, is a mess. You can continue headers from one line to another. You can embed comments into header values. Seriously. Comments. In a protocol's messages. It's moronic and indefensible. Why anyone would prefer that is probably them thinking that text equals easy to implement or something like that.

[jimktrains2]

I never said HTTP/1.1 is perfect. There are many possible optimizations and fixes possible, of which you've alluded to one.

[frankzinger]

Only the framing is binary. The PDUs are actually still plain text and 95% (perhaps more) of the semantics of HTTP/1.1 have been retained. Just pointing it out because your comment makes it sound like HTTP/2 is completely binary.

Also, how is HTTP/2 more bloated than HTTP/1.1? It simply adds a little framing; most of the bloat of HTTP/1.1 is retained. And as others have pointed out, HTTP/1.1 is hardly 'simple'.

Somebody on the IETF HTTP WG mailing list (may have been PHK himself) pointed out that their server (Varnish?) spends something like 30% of its CPU time parsing/processing just the Date header because it's in plain text. Plain text is not a panacea. We have nice tools like Wireshark these days which make it much easier for humans to read both binary and plain text protocols.

[jimktrains2]

> Just pointing it out because your comment makes it sound like HTTP/2 is completely binary

Functionally what's the difference? If I'm unable to read the entire message without a decoder, does it matter if I can read part of it?

> It simply adds a little framing;

I think yo forgot the whole reïnventing Layer-4 in Layer-7 thing. That is a travesty -- adding tons of complexity to solve a problem that it shouldn't be solving.

> We have nice tools like Wireshark these days which make it much easier for humans to read both binary and plain text protocols.

And the more tools _required_ to debug a problem, the harder it becomes to debug.

> spends something like 30% of its CPU time parsing/processing just the Date header because it's in plain text.

Plain-text is not a panacea, however I believe it preferable to a binary protocol for ease of debugging and hackability. If there are issues like the HTTP Date is causing trouble for many people, maybe we should look into how that could be made easier? A better format? Does the Date header even need to exist? (I actually don't think it does, along with Server, UA, and a couple others).

Additionally, I really wish that HTTP/2 would have actually attempted to solve problems faced by smaller HTTP users, and not force a behemoth of complexity (remember Layer 4 in Layer 7) on users who do not want that. I outline what I was hoping to be solved at https://github.com/jimktrains/http_ng.

[enneff]

HTTP/1.1 is also pretty bloated, it's just half the features nobody bothered to implement correctly (pipelining, for instance). HTTP/2 is much the same.

[anon1385]

>This is going to make the web so much faster, particular on mobile devices.

The performance benefits are overblown: https://news.ycombinator.com/item?id=8890839

[enneff]

HTTP pipelining doesn't work in practice, so comparing it to SPDY or HTTP/2 is a waste of time.

[bsdetector]

Every Android phone was using pipelining until Google removed it. Every iOS device uses pipelining since iOS 5.

These phones work in practice.

[cletusw]

That's one powerful yet easy-to-understand example!

[josteink]

> Check this out: https://http2.golang.org/gophertiles

This page confirms that I'm not using Google's trainwreck protocol and tells me the config-parameters I need to ensure I keep my browser this way.

    Unfortunately, you're not using HTTP/2 right now. To do so:
    Use Firefox Nightly or go to about:config and enable "network.http.spdy.enabled.http2draft"
    Use Google Chrome Canary and/or go to chrome://flags/#enable-spdy4 to Enable SPDY/4 (Chrome's name for HTTP/2)

This is quite good, although probably not for the reason the original authors intended.

[citrin_ru]

> I got a copy of Paul-Henning Kamp's critique "HTTP/2.0 - The IETF is Phoning It In" off the ACM website before the link went dead

There is a copy in maillist http://lists.w3.org/Archives/Public/ietf-http-wg/2015JanMar/...

[guelo]

Who exactly was it that voted for HTTP2? Is the debate leading up to the vote public?

[wmf]

https://lists.w3.org/Archives/Public/ietf-http-wg/