HTTP/2 - the IETF Is Phoning It In

An anonymous reader writes HTTP/2 is back in the spotlight again. After drawing significant ire over a proposal for officially sanctioned snooping, the IETF is drawing criticism for plowing ahead with its plans for HTTP/2 on an unrealistically short schedule and with an insufficiently clear charter. A few days ago the IETF announced Last Call for comments on the HTTP/2 protocol.

Poul-Henning Kamp writes, "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."

"Given this rather mediocre grade-sheet, you may be wondering why HTTP/2.0 is even being considered as a standard in the first place. The Answer is Politics. Google came up with the SPDY protocol, and since they have their own browser, they could play around as they choose to, optimizing the protocol for their particular needs. SPDY was a very good prototype which showed clearly that there was potential for improvement in a new version of the HTTP protocol. Kudos to Google for that. But SPDY also started to smell a lot like a 'walled garden'."

"The IETF, obviously fearing irrelevance, hastily 'discovered' that the HTTP/1.1 protocol needed an update, and tasked a working group with preparing it on an unrealistically short schedule. This ruled out any basis for the new HTTP/2.0 other than the SPDY protocol. With only the most hideous of SPDY's warts removed, and all other attempts at improvement rejected as 'not in scope,' 'too late,' or 'no consensus,' the IETF can now claim relevance and victory by conceding practically every principle ever held dear in return for the privilege of rubber-stamping Google's initiative."

Comments

HTTP isn't why the web is slow

[Anonymous Coward]

A typical "modern" web site loads untold numbers of scripts and other files from dozens of domains, mostly for tracking, A/B testing and other things that the user doesn't want or need. That's what makes the web slow. I don't think HTTP is a particularly nice protocol, but HTTP/2 is taking a bad protocol and making it worse by "optimizing" it, while the real bottleneck is obviously somewhere else.

Re:HTTP isn't why the web is slow

[greg1104]

Whenever I bring a new computer up, I'm shocked all over again at just how slow browsers are before ad blocking is enabled. On most sites, all of the real content is there long before all of the ad and tracking content arrives. Today, nothing speeds up a slow computer and connection like Adblock Plus.

Microsoft doth protest too much?

[Anonymous Coward]

I see no hidden agendas possible in this article. No, really..

Re:Shrug

[Anonymous Coward]

The only "bad" thing about XHTML is that it forced web developers to do things properly.

Web developers are generally total amateurs, or the worst of the worst of the so-called "professionals".

So expecting them to put even the slightest about of care into their work is just too much. That includes properly closing markup tags.

XHTML was admired and used very effectively by the very small proportion of real software developers who get stuck dealing with web development now and then.

But a small number of people can't compete with the overwhelmingly huge majority of incompetents, and their half-assed HTML5 idiocy.

Re:Shrug

[mwvdlee]

IPv6 doesn't suck. We're just not feeling the pain of IPv4 enough to care.

Re:Shrug

[mwvdlee]

The problem with XHTML is that it would never be able to stand on it's own.
Even if all web developers started creating perfect XHTML code, we'd still have a huge legacy that would require all the browser kludges XHTML was supposed to fix.
XHTML is best described as such: http://xkcd.com/927/

versus 20 years for IPv6. 2002 cutover to IPv6

[raymorris]

HTTP/2, like Java, was written with the time frame in mind, ad it was decided that it's better to release a good specification soon than insist on a perfect specification that's never finished and deployed. There is a reason for that - a number of reasons, actually, but the #1 reason is IPv6.

On April Fool's day 2002 I announced that the backbones, root name servers, and other core infrastructure would be doing a cutover to IPv6 and we expected a few hours of downtime for the internet as a whole. The story was believable because IPv6 had been in the works for a couple of years and switchover at that point seemed logical, if the reader wasn't a network engineer.

Thirteen years later, 95% of internet traffic is still IPv4. Ten or twenty years from now, do we want to be using a better version of HTTP, or still be using HTTP/1.1 and talking about HTTP/2?

Re:HTTP/1.1 is just fine

[DarkOx]

Bandwidth is bigger and cheaper than ever. So why?

In places where its being delivered by cable to the edge or damn near to the edge yes. The rest of the world not so much.

Think about. Anywhere dense enough AND stable enough pretty is pretty well covered for highspeed Internet access.

The problem is everywhere else, is being more and more covered by Cellular. There is only so much spectrum, there are laws of physics that place caps on just how much information can be sent there.

So you have trouble on both ends. You have very high population places, us westerners might think of as slums where people want to run lots of cellular radios. You can only get so far with micro cells and wifi. After all the micro-cell or wifi have to connect to something. If the cell is to small you could have just pulled the cable or fiber in.

Ditto for sparsely populated areas. You again get lots of people on one tower there as well (but using more TX power) again because its only economical and practical to put so much density in. Satellites have essentially the limitations.

We are approaching the point were many of high bandwidth have nots are likely to remain have nots pretty no matter what policy well meaning pols come up with it; because at some point basic economic reality slaps you in the face. Yes there is still plenty of USA to cover, we got just about everyone power and phone 60+ years ago, fast Internet will get there too but it will take time.

I don't think we should let trying to keep bandwidth requirements held to a minimum stand in the way of solving real problems and doing new things, but I also don't think its a good or fair idea to just completely say "fuck it" with regard to something like protocol overhead.

Re:HTTP/1.1 good enough?

[Anonymous Coward]

As an implementer of HTTP/1.1 and participants of the HTTP WG, I can say that HTTP/1.1 has many defects, the worst one is that people *think* they get it right without reading the docs. When you read the docs, you realize how many corner cases you can accidently get into. Most of them are caused by the inheritance of HTTP/1.0 where content-length was not needed. Other important issues concern the need to differenciate idempotent vs non-idempotent requests when you want to reuse an existing connection. It goes as far as requiring the client to retry if the server closed too fast, but not always, only if it's safe, and basically only the user really decides if it's safe... Ambiguous parsing is also a major concern. Many implementations think that the "Connection" tokens are case sensitive while they're not since they're supposed to be header names except for "close" which is not. Some don't understand "Connection: Close" because of this. Header folding with commas is an issue since you don't know what header contains multiple values and what header contains a single value which contains commas (eg: date). Just pass two content-length values and pray for the right one to be correctly parsed, otherwise the rest of the body will be understood as a next request. Date headers are hard to parse. Host header is a hell. Just pass two of them to have fun with some sites, or pass "Connection: host" and see some of them dump the root of the virtual hosting directory. Headers length is unlimited and can be folded on multiple lines if the next line starts with a space or a tab (which does not count in the value). So no, HTTP/1 is not good. And that's why it succeeded. In history most success results from not good designs, but the ones that are easy to get approximately right in a short time, ie: write a vulnerable server in CGI scripting. This is the part where HTTP/2 improves things. But some other parts are worse.

Willy

Re:Proposals and running code

[dackroyd]

But at first glace it doesn't look that bad.

I can see the appeal of rubberstamping what already exists.

That's the real problem with the proposed protocol; it solves today's problems for todays computers. It doesn't attempt to look ahead and solve problems that should be solved over the next ten years.

Seeing as it's going to take a few years and a huge amount of effort before HTTP 2 is widely adopted, we're going to need to start working on a replacement for it's even finished its rollout.

Poul-Hennings has written his thoughts on the problems that actually should be solved in the next version of HTTP: http://phk.freebsd.dk/words/ht...

The fact that the IETF has decided to ignore those problems so that HTTP 2 can be pushed out the door is what makes the situation be such a joke. Almost the only entities that will benefit from having HTTP 2 in the next 5 years are companies that have a web presence on the same scale as Google, Facebook, Twitter etc. that will save a small amount of money through reduced bandwidth costs.

For everyone else, rolling out HTTP 2 will be a massive initial and ongoing technical burden, with almost no benefit.