5 ms·

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

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

wmf 12y ago
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 12y ago
  > 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.
guelo 12y ago
Who exactly was it that voted for HTTP2? Is the debate leading up to the vote public?
- wmf 12y ago
  https://lists.w3.org/Archives/Public/ietf-http-wg/ https://lists.w3.org/Archives/Public/ietf-http-wg/
magicalist 12y ago
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 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:3i6EwF7CyHMJ:queue.acm.org/detail.cfm%3Fref%3Drss%26id%3D2716278+&cd=2&hl=en&ct=clnk&gl=us https://webcache.googleusercontent.com/search?q=cache:3i6EwF...
enneff 12y ago
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 https://http2.golang.org/gophertiles This is going to make the web so much faster, particular on mobile devices.
- cletusw 12y ago
  That's one powerful yet easy-to-understand example!
- jimktrains2 12y ago
  > 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.
  - enneff 12y ago
    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.
  - MichaelGG 12y ago
    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 12y ago
      I never said HTTP/1.1 is perfect. There are many possible optimizations and fixes possible, of which you've alluded to one.
  - frankzinger 12y ago
citrin_ru 12y ago
> 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/0043.html http://lists.w3.org/Archives/Public/ietf-http-wg/2015JanMar/...
runeks 12y ago
> 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 12y ago
  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 12y ago
  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 12y ago
    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 12y ago
  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.

wmf 12y ago

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 12y ago
> 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.

guelo 12y ago

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

wmf 12y ago
https://lists.w3.org/Archives/Public/ietf-http-wg/ https://lists.w3.org/Archives/Public/ietf-http-wg/

magicalist 12y ago

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 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:3i6EwF7CyHMJ:queue.acm.org/detail.cfm%3Fref%3Drss%26id%3D2716278+&cd=2&hl=en&ct=clnk&gl=us https://webcache.googleusercontent.com/search?q=cache:3i6EwF...

enneff 12y ago

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 https://http2.golang.org/gophertiles This is going to make the web so much faster, particular on mobile devices.

cletusw 12y ago
That's one powerful yet easy-to-understand example!
jimktrains2 12y ago
> 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.
- enneff 12y ago
  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.
- MichaelGG 12y ago
  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 12y ago
    I never said HTTP/1.1 is perfect. There are many possible optimizations and fixes possible, of which you've alluded to one.
- frankzinger 12y ago

citrin_ru 12y ago

> 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/0043.html http://lists.w3.org/Archives/Public/ietf-http-wg/2015JanMar/...

runeks 12y ago

> 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 12y ago
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 12y ago
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 12y ago
  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 12y ago
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.