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

Shrug

[Anonymous Coward]

If the protocol sucks, it'll go mostly unadopted.

See also: xhtml and arguably ipv6

Re:Shrug

[Anrego]

What made xhtml suck. As a non-web guy who just occasionally dabbles, xhtml seemed like a good idea. Unclosed tags in html always looked ugly, and as far as I can tell, that's really the most notable difference between xhtml and html.

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/

Re:Shrug

[Anonymous Coward]

I still code in mostly xhtml. I mean, I add html5 tags when needed, but I treat it like XML.

Except for tags. I don't bother with cdata sections since that tends to confuse many browsers

Re:Shrug

[Anonymous Coward]

Except they don't write up the HTML by hand. They just tools that write it for them after drawing it in Photoshop. Or they just export their Photoshop mockup as a giant image and call it a webpage.

Re:Shrug

[omnichad]

As a web guy, I still use primarily XHTML. I may call it HTML5 when I need to use an HTML5 tag, but for a true developer/designer who doesn't use a GUI, properly nesting tags is a must. And with HTML5 being so loose, most XHTML documents are also valid HTML5 documents.

Also - being able to load another web site's XML-compliant DOM to scrape data (for personal use)? Priceless.

Re:Shrug

[MagickalMyst]

"If the protocol sucks, it'll go mostly unadopted."

Not necessarily.

Micro$oft Windows is the 'industry standard' in many parts of the world. It uses a protocol called NetBEUI.

Re:Shrug

[Anonymous Coward]

Odd examples. XHTML worked quite well and, by all appearances, overtook HTML 4 in adoption. IPv6 is generally quite highly-regarded, but more effort is placed on mitigating the problems with IPv4 due to the chicken-and-egg situation.

Re:Shrug

[Anonymous Coward]

I understand where you're coming from. I take great pride in writing clean, maintainable code that will render as uniformly as possible in all browsers. I even got fired from a job because I insisted on adhering to standards. The owner of that company did me a huge favour and I consider that day one of the best days of my life.

Re:Shrug

[Anonymous Coward]

The prevalent opinion on web developers at slashdot is so far from the reality it's funny. Just because you've been forced to work with terrible devs doesn't mean that's an accurate portrayal of the profession.

Re:Shrug

[Lennie]

Let's not kid ourselfs.

We all make mistakes.

Especially when we start to generate HTML based on different sources.

One mistake meant: the visitor on the webpage got to see an error instead of most of the page when you are not using XHTML.

XHTML was just to complicated, not flexible enough and strict.

Could it be that is also the reason JSON is now much more popular than XML ?

Re: Shrug

[Anonymous Coward]

So where are these web devs who aren't total crap?

Web apps have always sucked. They're usually worse now than ever before. Just look at Slashdot Beta for proof of that. I can't think of any web app that I'd consider good. GMail is awful these days. Google Maps is terrible now. Facebook is a mess. Wikipedia is getting worse. Internal corporate apps are complete crap.

If web devs are so great, as you claim, then why are all web apps so awful?

Re:Shrug

[Anonymous Coward]

IPv6 doesn't suck.

Having gone thru my 4th IPv6 stack on my router last year, I am beginning to wonder...

So far this last stack seems at least stable and not as crashy. I give it at least 2 more years before it is solid and people do not think about it. However, when my wife comes to me and says 'google does not work again' and I find out it is ipv6 on the router again I will turn it off and pout...

However, pretty soon IPv4 is going to crunch. The core routing tables are wildly fragmented at this point. Especially now you have the people who swooped up large chunks selling them off a little at a time.

The one thing that torks me off is they pretty much ignored cachability other than local to the box. It seems they went out of their way to make it harder.

Re:Shrug

[petermgreen]

ways in which IPv6 sucks or sucked.

1: mechanisms for interoperability were bolted on later, not included as core features that every client and router should support and enable by default. The result is that relays for the transition mechanisms are in seriously short supply on the internet and often cause traffic to be routed significantly out of it's way.
2: the designers were massively anti-nat, as a result we don't have any interoperability mechanisms that go with the flow of NAT, instead we have two incompatible interoperability mechanisms one of which doesn't work with NAT at all and the other of which makes itself unnessaceraly fragile by fighting the NAT rather than going with it. The company behind the latter mechanism also disabled it by default for machines on "managed networks"*, presumablly because they were afraid of annoying corporate network admins.
3: there was lots of dicking around with trying to solve other problems at the same time rather than focusing on the core problem of address shortage. For example for a long time it was not possible to get IPv6 PI space because of pressure from people who wanted to reduce routing table size. Stateless autoconfiguation and the elimination of NAT seemed like good things at the time but they raised privacy issues and added considerable complexity to home/small buisness deployments.
4: there was little incentive to support it and so the time when you can use an IPv6 only system as a general internet client or server without resorting to transition mechanisms seems as far off as ever.

* Defined as any network with something windows thinks is a domain controller.

Re:Shrug

[neoform]

JSON is very simple, but it's also very strict. A single typo will result in no data being readable.

Re:Shrug

[allo]

you can't use the same cartoon for all matters. this is not a problem of a competing standard.

Re:Shrug

[hab136]

You forgot DHCPv6 being rejected because stateless autoconfig/RAs would be enough - except you couldn't get DNS or PXE boot info that way because it's not part of routing, so couldn't be included in router advertisements (politics, not technical). So, DHCPv6 was bolted on after.

Re:Shrug

[allo]

boils all down to the same: When you need to break a protocol (you need to, because of bigger addresses), then take the opportunity to fix all other mistakes as well.

Re:Shrug

[CastrTroy]

The "problem" with HTML and browsers is that they have always worked with, and will always be expected to work with invalid code. Feed invalid code into a C compiler, a Java compiler, or XML interpreter, and if the syntax is incorrect, it will return an error and refuse to process anything. Browsers on the other hand are supposed to take invalid HTML and try to do something useful with it. If browser developers didn't have to spend so much time trying to make their code interpret invalid syntax, they could probably fix a lot of the other bugs that actually affect valid code.

Re:Shrug

[mwvdlee]

It's a problem of trying to solve the problem of bad standards by introducing yet another standard, which ends up not replacing any of the old standards.

Re: Shrug

[Anonymous Coward]

XHTML misrendered compliant HTML4 code, despite claiming to be fully bwcompat. To make matters worse, direct-closing tags such as br/ will foul up the sgml parser used by HTML4.

As far as I can tell, when this set of screwups became public knowledge as about the time xhtml went from perceived as the next best thing to a bad idea.

Re:Shrug

[mwvdlee]

OTOH, A typical web developer has to spend a lot of time trying to create a single HTML codebase that works across all browsers.
Restrictive syntax validation in browsers wouldn't be as big a problem if all browsers could agree on what that syntax actually does.

Re:Shrug

[Anonymous Coward]

IE6 didn't properly support XHTML and that caused it to die on the vine. It could only interpret it as HTML and even that required hacks on either the server side or client side. XHTML documents either needed to be served with the wrong MIME type (text/html rather than the proper application/xhtml+xml) or the client needed to add registry entries, but that also required serving files with a .xhtml extension. Even with that, not all features of XHTML were usable since it was being interpreted as HTML.

Re: Shrug

[Anonymous Coward]

That's the funny thing about web developers. They can in fact handle strict data formats like JSON and XML. But the moment it involves a data format that they consider to be markup, they go completely stupid and become unable to handle any strictness or consistency at all.

Re: Shrug

[Anonymous Coward]

Dude, he was talking about web devs being too lazy and/or incompetent to properly close HTML tags.

This isn't about the bugs that everyone is capable of introducing.

This is about failing to get the syntax right!

Re:Shrug

[Anonymous Coward]

One mistake meant: the visitor on the webpage got to see an error instead of most of the page when you are not using XHTML.

No, one mistake meant the "compiler" barfed, gave you an error message, and you went back and debugged your shit.

1) Don't develop in production.
2) Test before you push to production.
3) Don't develop in production.
4) Computer programming requires very specific input to generate correct and working code.
5) Don't develop in production.
6) Users only see the final output, so be sure that it's working before you release it for them to see.
7) DON'T DEVELOP IN PRODUCTION, YOU STUPID NEWBIE.

Now, I understand that you, the parent poster, are probably not a newbie (you have a low ID from back when /. was actually for nerds). But the point stands that you shouldn't let a compilation bug ruin your release. And all those "web developers" need to learn a hard lesson, the one that goes about like this: When you write code and it doesn't work, it's your fault, not the compiler's. So fix it. Fix it before you release it for the world to see your failures.

I've used a lot of XHTML (ASP.Net is entirely based on it), and it's quite easy to work with. Especially if you're not luddite that shuns modern tools like real-time syntax checkers and pre-compilers that are built in features of just about every IDE now.

Re:Shrug

[Anonymous Coward]

It is invalid in any true HTML standard to close an input, option, or any of a few other tags, either by a closing tag or by a trailing slash. But it's a "forgivable sin" to most HTML parsers, which will happily ignore such closing tags when parsing your XHTML.

Re:Shrug

[ArhcAngel]

Oh the irony...

Or did you intentionally bork the <quotes> tag?

Re:Shrug

[Anonymous Coward]

Right, but that problem only exists because browser vendors have repeatedly shown they're some of the worst software developers about and don't have the foggiest how to write good code. Hence why browsers have always had problems with sluggishness, security flaws, and sometimes poor stability as well as being unable to cope with simple things like this.

If Word can cope with multiple XML formats as well as a number of binary formats there's no fucking reason a web browser couldn't other than ineptitude. It's just about making sure your code is well structured and uses abstractions and interfaces where necessary. Apparently all browsers are too shitly written to do any of this though and last time a Firefox dev came here and tried to make excuses he only served to demonstrate how bad browser developers actually are and proved the point.

It's just sad that the web is held back by the very people whose job is to build the gateway to it because they're too inept and too busy trying to build pointless operating systems no one gives a shit about and other stupid pet projects.

Re:Shrug

[Anonymous Coward]

Maybe there should be a new standard for when ole 927 is applicable.

Re:Shrug

[Anonymous Coward]

> XHTML was just to complicated, not flexible enough and strict.

If you find XHTML too complicated you probably shouldn't be creating web pages in the first place because you might hurt yourself. It was actually more flexible, that's kind of what the fucking X in XHTML means - eXtensible.

> Could it be that is also the reason JSON is now much more popular than XML ?

No it couldn't because it's not. Not even close. XML still powers every web service going for starters because SOAP and WSDL.

Re:Shrug

[Anonymous Coward]

Yes, but unfortunately only because dumb people like Ian Hickson spread a load of FUD about it simply because their minds were too simple and used to producing bad quality markup due to a fundamental lack of software engineering knowledge further illustrated by the horrendous clusterfuck that is the HTML5 spec.

The HTML5 spec is like a 3 year old's scribblings whilst the XML spec is like Shakespeare's finest work in contrast. Unfortunately for some reason the keys to the web seem to have been handed to the 3 year old. Maybe just too many web developers are 3 year olds and so it suits them better because they just can't produce quality software hence why we also see so many dumb web security mistakes nowadays?

Re: Shrug

[jeremyp]

This is utter nonsense. XHTML is not a an HTML renderer, it is a standard for an XML document format.

If your browser misrenders an HTML4 document because it thinks it is XHTML, the problem is either the browser itself which can't distinguish different document types or the person who wrote the web page and erroneously put the xml processing instruction at the top.

Re:Shrug

[jeremyp]

They just tools that write it for them after drawing it in Photoshop.

Should that be "they just use tools" or "they just are tools"?

Re: Shrug

[Anonymous Coward]

So where are these web devs who aren't total crap?

Mostly programming in real languages, while barely touching on HTML in their day jobs.

Re:Shrug

[Anonymous Coward]

The HTML syntax was never the issue: there was always a well-defined intersection of interoperable tags in HTML (just exclude blink, marquee, etc, and stick to the known set that actually describes your content instead of controls presentation). CSS and JS were the problem, because nothing ever fucking worked according to spec across all the browsers. CSS3 is still a minefield.

XHTML was actually a strict interpretation that was very well supported everywhere. You can still write HTML5 with the well-formedness of XHTML (even attributes like itemscope can take the form itemscope="itemscope" for compatibility) and create HTML5 off other XML via XSL. XSL was really the key benefit of XHTML: being able to turn any XML format (like TEI) into HTML client-side was a godsend. I still use it everyday.

Re:Shrug

[unixisc]

1. Was it? IPv6 was defined w/ what was thought would be transition mechanisms - IPv4 compatible addresses, and IPv4 mapped addresses. However, they weren't what worked for transitions, which is why they thought out techniques like tunneling, LSNAT, Dual Stack, DS-lite and so on.

2. They did write an NAPT standard for those who just have to have NAT. It differs from NAT44 in that it's a 1:1 mapping b/w public and private addresses (I'm being colloquial here) rather than many:1 that you have in NAT44. So you still have the advantages of a hidden network behind a router, no need for renumbering and most importantly, load balancing. The only thing they don't have now - many:1 mapping of addresses - is unneeded in IPv6

3. I agree that stateless autoconfiguration, while good, was made too easy at the cost of making routable address tables. Had they reserved just the lower 32-bits for the interface ID, they could probably have achieved their simplified routing tables. Also, while defining several address types & scopes, they didn't initially make the role of each clear. Had it been plain that nodes would have not just link local and global unicast, but also site unique addresses, there wouldn't have been such a pressure for PI addresses. Plus, had the above definition of 96+32 been done, PI addresses would probably have been easier to assign as well

4. This part is true, and part of the reason was IPv6 deprecating defined standards as it went along, like IPv6 compatible addresses and site local addresses. Gave ammo to those claiming that the standard was still fluid

Re:Shrug

[0123456]

The problem is, when www.somecraphpytmlsite.com doesn't display in the web browser, users blame the browser, not the crap HTML writers.

It's like the good old days of writing device drivers for Windows, where we had to reproduce bugs from the default OS drivers in our custom drivers becasue there were so many crappy apps which only worked because of those bugs, and people would complain to us that CrappyWord Xtreme didn't work after they installed our driver which didn't have those bugs.

We should have tossed the whole thing long ago, and told people to fix their crap. Backward compatiblity sounds good, but it kills you in the long run.

Re:Shrug

[unixisc]

I recall reading about DHCPv6 right from the start. Problem was that autoconfig/RAs were thought to be magic bullets, w/o considering that admins may like to have control over how addresses were assigned.

Autoconfig - particularly EUI-64, is fine for link local addresses and maybe even for site local (fd00::/8) addresses. It's a bad idea to use w/ global unique addresses, which would be better off managed by DHCP6.

However, any IPv6 node not just can, but will have multiple IPv6 addresses. So it can have a link local, site unique and several global unique addresses, depending on how many external routers provide it redundant connectivity

Re:Shrug

[Dragonslicer]

They just tools that write it for them after drawing it in Photoshop.

Should that be "they just use tools" or "they just are tools"?

Yes.

Re:Shrug

[Bengie]

NAT is a crutch with no valid use case other than "I can't do it correctly, so I'll fudge the data flow". It's an evil required to handle the limits of IPv4, but is being abused for many other reasons; I can't wait for it to die in a holy fire.

Re:Shrug

[jandrese]

This was the dumbest thing. Not including the basic DNS functionality in the router advertisement--on a protocol utterly dependent on DNS because the addresses are so ugly--was a colossal blunder. Even then, stateless autoconfig has no mechanism to notify the DNS of the address it chose, so good luck populating a DNS server. Sure you don't need a hostname if you're purely a client, but that's far too narrow a view for how people actually use networks. I like a lot of what IPv6 does and think that in 10-15 years v4 will be a historic relic used in legacy networks and by old equipment, but it has some ugly warts right now.

I understand that the designers thought DNS was "just a service", but it's not. It a mapping tool for addresses at the IP layer. It's right there and more importantly, it has direct interaction with the IP layer. It should have been at the table during the IPv6 development.

Re:Shrug

[WaffleMonster]

1: mechanisms for interoperability were bolted on later, not included as core features that every client and router should support and enable by default. The result is that relays for the transition mechanisms are in seriously short supply on the internet and often cause traffic to be routed significantly out of it's way.

The Internet is a production network. You either deploy IPv6 fully in a production quality matter or don't do it at all. The mistake was in developing transition mechanisms in the first place which have done nothing but get in the way of adoption.

there was lots of dicking around with trying to solve other problems at the same time rather than focusing on the core problem of address shortage. For example for a long time it was not possible to get IPv6 PI space because of pressure from people who wanted to reduce routing table size.

Not everyone in the world has access to the same buying power enjoyed by rich western states. *Someone* ultimately has to pay for PI, rinky-dink multi-homing and lazy TE shenanigans. It is a political calculation whom that should be.

Stateless autoconfiguation and the elimination of NAT seemed like good things at the time but they raised privacy issues and added considerable complexity to home/small buisness deployments.

Reality is IPv6 privacy extensions were widely deployed in a landscape already dominated by browser fingerprinting, browser cookies, plugin cookies, DNS fingerprinting.

Re:Shrug

[sjames]

For years, I had 6to4 working through a NAT just fine.

Teredo was disabled by default on managed networks because it was effectively bypassing the firewall. It was a significant security risk.

3 was a problem external to the scope of the protocol spec driven by a bunch of anemic routers. 3a (stateless autoconfig, no NAT) work quite well if you have a router that supports v6. They greatly simplify home and SOHO configurations (do nothing and it works). The privacy issues have been fully addressed. Filtering rather than NAT greatly reduces the load on the router.

It is being deployed. I no longer maintain my 6to4 setup since I now receive a prefix from my ISP.

Re:Shrug

[WaffleMonster]

Browsers on the other hand are supposed to take invalid HTML and try to do something useful with it. If browser developers didn't have to spend so much time trying to make their code interpret invalid syntax, they could probably fix a lot of the other bugs that actually affect valid code.

While it may well be more difficult to write an HTML parser this effort is an insignificant rounding error when considered within context of effort needed to produce a modern browser stack.

Re:Shrug

[Lennie]

Let's see how many new and existing APIs use JSON in comparison to XML:

http://www.programmableweb.com...
http://www.programmableweb.com...

Seems like a pretty clear trend to me XML is on the way out.

SOAP or WSDL you say ?:

Well, usually you use JSON with REST.

At the last technology conference where they all immplement 'micro services'. I asked several people does REST/JSON need a WSDL-like solution:
They all answered: no

If you want to describe your REST/JSON API, there are solutions though:

https://helloreverb.com/develo...
http://raml.org/

Re:Shrug

[disambiguated]

XHTML serves a purpose. It adds the eXtensibility so that XHTML can be encorporated into other XML documents and visa versa, and it allows you to parse, generate and manipulate it with XML tools. The fact that browsers still have to deal with non-XML HTML doesn't take away from it's advantages.

If you're generating HTML, there's no reason to not generate XHTML -- it's only the code that consumes it that has to deal with HTML. And what, besides a browser, consumes HTML? (Whatever it is, it's probably doing it wrong.)

Re:Shrug

[MikeBabcock]

XHTML sucks because websites are not well-defined as content; they're a mix of content and software and layout (unfortunately) and therefore a single XML file doesn't well describe what it needs to contain. If HTML were replaced by a whole new content system, it could be well-defined and described by XML but HTML isn't it.

Re:Shrug

[unixisc]

Aside from the address conservation issues, which is a problem, NAT does have few things that are attractive to network admins:

1. It abstracts networks behind the firewall so that an external malicious app wouldn't know what to look for

2. In the absence of PI addresses, it enables a network to have a permanent internal address topology that would remain unchanged even if global unicast addresses changed due to changing an ISP, or an ISP itself changing addresses

3. It enables load balancing

This is why the IETF, despite not wanting it in IPv6, has defined an NAPT standard so that in case any adaptor wants to use NAT w/ IPv6 for the above reasons, they can. Note that the traditional Port Address translation that you had in IPv4, where you had a few public addresses mapped on to several more private addresses, has been eliminated. So now, one would just have 1:1 mapping of addresses.

Aside from that, end to end communications is back w/ IPv6.

Re:Shrug

[unixisc]

Problem w/ the first issue is that in the real world, no transition is an overnight transition from X to Y. Y starts getting adapted, tested for problems, and once verified that there are none, adaption of Y accelerates, and X declines. Given that fact, there had to be transition mechanisms in place

Buying PI address blocks is something networks need, whether in the US or Malawi. But it was a good idea to try and reduce routing tables: too bad that idea fell by the wayside. As I noted above, had they split the prefix and interface ID differently, instead of 64:64, such as 96:32, they'd have been able to do both - have RIR delegated prefixes, as well as a range for international organizations that wanted PI addresses.

Privacy extensions are good, but become an issue when the admins want more control over which addresses go to what. That's when DHCP6 is a good idea

Re:Shrug

[shutdown -p now]

In HTML5, the usual XML syntax for self-closing tags is reinterpreted to basically just ignore the slash and treat it as a start tag (and then automatically close it if it's an element that demands such) - so <input/> is exactly equivalent to <input>, and as such is valid HTML5.

Re: Shrug

[chriscappuccio]

You'll have to explain why they're crap.

Another standards committee bites the dust.

[Anonymous Coward]

Depressing, actually. "Market forces" trump "doing it right", to the detriment of us all.

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

[Anonymous Coward]

And web browsers load all that shit because web developers tell it to.

Let's not blame browsers or protocols for shitty design and the fact that the Web has turned into just a big marketing platform - like TV. The content is just to get you to look and click on ads.

I was at an interview a while ago at a web development/SEO/advertising company and the no-scripts and ad-blockers came up. The dude interviewing me said something to the effect that he couldn't understand why people would ruin their online experience or something like that.

Those people actually think they are adding value to the web; when they are parasites sucking the bandwidth and making the web an annoying and slow place.

even with my ad-blockers, no-script, hosts file to block BS, my 1.5mbs/.25mbs connection is getting long in the tooth and my web pages look like those old censored letters from WWII - you know where they cut out everything that might give the enemy help.

The advertising and social media companies have turned the web into a mostly lame-ass place loaded with garbage content.

Re:HTTP isn't why the web is slow

[Austerity Empowers]

I was unable to read your post because it didn't contain any pictures to look at or a monkey I could punch.

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.

Re:HTTP isn't why the web is slow

[omnichad]

Part of the reasons for dozens of (sub)domains is because even modern browsers still have a connection limit per host. And there's a lot of overhead in establishing an HTTP connection. If you're loading lots of tiny files, it makes sense to download them all through one HTTP connection. HTTP/1.1 already has pipelining, but almost no server is set up to use it.

Re:HTTP isn't why the web is slow

[omnichad]

I think the major ad networks have some serious bottlenecks. Always the last thing to load. You would think that fixing that would be a huge priority considering it leads to people installing Adblock. That's the primary reason I've installed it for people - not because the sites they go to have ads in intrusive locations.

Re:HTTP isn't why the web is slow

[Anonymous Coward]

No. There are web authoring techniques for aggregating lots of tiny files, but in typical scenarios where they're still necessary (for example user icons on forums), they're loaded from a single domain after all. The prevalent reason for using (sub)domains is content distribution networks: In order to load static content from a CDN and still have the dynamic parts of the web page handled by your own servers, you typically create another domain for the static content. Due to the way cookies are handled, that domain is now more often than not a separate second-level domain, not a subdomain of the main domain. Web sites with user generated content also often place that content on a separate domain for security reasons.

Those are not the domains I'm talking about. Web sites are littered with third party content, usually scripts. Slashdot isn't even a big offender in that regard, but the page I'm looking at right now wants to load from all of these domains: fsdn.com, rpxnow.com, taboola.com, googletagservices.com, google-analytics.com, perfectmarket.com, scorecardresearch.com, gstatic.com, zedo.com, googleadservices.com and googlesyndication.com. Of these, only one is needed to get a fully working web page: fsdn.com. I count five domains belonging to Google, so it's easy to see why Google in particular wants to optimize the hell out of the transport protocol. There's a certain irony to Google recommending that web authors make sure their pages load quickly. Again, Slashdot's use of third party content is almost the bare minimum. Hipper web sites easily pull in content from 20 or more domains, and when I say "content" in this context, I mean stuff that the user doesn't want or need.

Re:HTTP isn't why the web is slow

[Gaygirlie]

A lot of the various Internet-engineers disagree with you. Have you looked at how much traffic is spent on nothing more than headers? There's a lot of stuff spent on those. Now, multiply that with the said scripts and other files you mentioned, with every single file or request generating all those headers. Then, multiply all that with the number of users accessing the servers, and you have shitloads of traffic eating away at your bandwidth all needlessly. There have been a lot of attempts all around that try to reduce this clutter, like e.g. Comet, WebSockets and so on.

You're only seeing things from the perspective of the end-users, but for those running servers or those providing the bandwidth it does really matter.

Re:HTTP isn't why the web is slow

[allo]

maybe they are the last thing, because a sane webdevelopers let the page load its important parts before it loads the ads?

Re:HTTP isn't why the web is slow

[Anonymous Coward]

No. If you want to reduce the amount of data transferred, compress images better, don't load entire script libraries for a single hover effect, etc. Headers are negligible compared to almost all content. Two examples: The favicon.ico file on theverge.com is 32kB. The sf-logo.png file on this web site is 25kB. So these are small files, right? But they're bigger than all the headers combined on each of those pages. I can save the exact same image data as the sf-logo.png file in 20kB less than the original file, and all it takes is a single parameter free invocation of a common image file compression tool. Headers are a red herring.

Re:HTTP isn't why the web is slow

[mellon]

Personally I have no opinion about HTTP/2, but I have to say that this anonymous hit piece looks a lot like some IETF participant who didn't like how the process came out trying to create the appearance of consensus against it by pumping up the anger of the interwebs without actually saying what's wrong with the spec. When I see people making statements not supported by explanations as to why we might want to consider them correct, my tendency is to assume that it's hot air trying to bypass the consensus process.

It's also a bit annoying to see the IETF accused of having published a document advocating snooping when in fact someone floated that idea in the IETF and it was shot down in flames, and what we actually published was a document stating that snooping is to be considered an attack and addressed in all new IETF protocol specifications (RFC 7258).

Re:HTTP isn't why the web is slow

[omnichad]

If the content is on another domain, it loads simultaneously in a separate HTTP request. It just takes longer to complete that smaller (but slower) request than it takes to load the entire rest of the web site.

And some web sites don't define a fixed width/height for the ad, meaning the page (or big chunks of the page) doesn't actually render until the ad finishes loading.

Re:HTTP isn't why the web is slow

[Afty0r]

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

I know this is a popular meme around here, and on the tracking side I am kinda with you (though it is nice to have ads which are more contextually relevant to me and this can help) but on A/B users DEFINITELY want and need this... it's a fantastic tool in making web sites better over time - meaning all users benefit from continued usage.

Arguing against A/B testing because "you don't want it" is like arguing against some of your taxes being used in medical research to cure disease - just because you are not getting a benefit today (you're actually LOSING money) does not mean it is a bad thing, or that you should attempt to not participate.

(as an aside, we still live in a world where many senior people with zero knowledge of website usage and user experience architecture still think they should be dictating layout/flow/features/content - and you cannot hit these people round the head with a clue by four... A/B testing is useful to show up their shitty ideas for what they are and keep the sites good).

Re:HTTP isn't why the web is slow

[Anonymous Coward]

Because they can't get reliable analitycs/tracking with caches, so there are always parts that are reloaded every time, multiply those with the number of share buttons/ads (also add scripts rolling different ads every time) so that even with HTTP inlining you get dozens of connections.

Re:HTTP isn't why the web is slow

[Anonymous Coward]

Plus, clients are generally limited to 6 simultaneous request on a standard connection, 2 over LTE and I think only 1 on slower mobile connection types. Mix together multiple ad networks, javascript libraries in a CDN, and who knows what else. The result is a quickly hit request limit.

Re:HTTP isn't why the web is slow

[Qzukk]

As a PHP developer I can tell you exactly where one huge bottleneck is: POST-Redirect-GET. The current paradigm for handling POST requests requires that I initialize my framework, load all my objects, create a new object, save it in the database then set fire to the whole thing and tell the browser to redirect to another page where I initialize my framework, load all the objects, recreate the object I just burned down and plug it into the relevant view.

Not being able to respond to a POST request with a view with a "if the user wants to bookmark this page or reload it, please GET this Location: instead" doubles the number of requests I have to serve and halves my throughput.

Re:HTTP isn't why the web is slow

[jdschulteis]

Personally I have no opinion about HTTP/2, but I have to say that this anonymous hit piece looks a lot like some IETF participant who didn't like how the process came out trying to create the appearance of consensus against it by pumping up the anger of the interwebs without actually saying what's wrong with the spec. When I see people making statements not supported by explanations as to why we might want to consider them correct, my tendency is to assume that it's hot air trying to bypass the consensus process.

It's also a bit annoying to see the IETF accused of having published a document advocating snooping when in fact someone floated that idea in the IETF and it was shot down in flames, and what we actually published was a document stating that snooping is to be considered an attack and addressed in all new IETF protocol specifications (RFC 7258).

What "anonymous hit piece"? Second link in the fine summary has a clear byline, Poul-Henning Kamp.

From the article:

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.

I too would like more details, but I doubt he's just blowing smoke here.

Re:HTTP isn't why the web is slow

[Bengie]

HTTP1.1 pipelining requires responses to be returned in the same order the requests were made. This means all requests are dependent on the other and one long running response can block all other responses behind it. HTTP2.0 "fixes" this.

Re:HTTP isn't why the web is slow

[omnichad]

When I said lots of tiny files I was referring to generally static content. But having all of these on one subdomain and the dynamic content on the primary domain name will allow this to happen asynchronously. Pipelining would still fix this as long as we don't let go of all our other current tricks.

Re:HTTP isn't why the web is slow

[WaffleMonster]

Part of the reasons for dozens of (sub)domains is because even modern browsers still have a connection limit per host. And there's a lot of overhead in establishing an HTTP connection. If you're loading lots of tiny files, it makes sense to download them all through one HTTP connection. HTTP/1.1 already has pipelining, but almost no server is set up to use it.

Completely disagree. RFC7413 is already an RFC unlike SPDY and already solves the problem of overhead for new requests using stateless cookies without keeping session state (e.g. tied up resources) open speculatively in anticipation of future reuse.

Multiplexing multiple streams within a single stream = Head of Line blocking. A problem that does not exist when using multiple independent streams are employed.

The same concept applied to TLS currently in the pipeline allows for requests to be processed by the application stack on the 0th round trip using HTTP/1.0 with no head of line blocking.

In essence deploying HTTP/2.0 is worse than simply addressing underlying deficiencies in TCP and TLS... Better still this effort carries forward and is reusable for other non HTTP based protocols.

Re:HTTP isn't why the web is slow

[omnichad]

The only reason you've given for HTTP/2.0 being worse is that it's not already an RFC. SPDY and by extension HTTP/2.0 does not have head of line blocking issues. The requests are multiplexed, but tagged, and requests can be answered out of order.

Head of line blocking is really only an issue for dynamic content. Pipelining all of your static resources through a single connection to a single subdomain is more efficient than multiple requests. And nothing is going to be stopping you from using your bandwidth. Sure, if you have some progressive jpegs, but those are almost completely out of use now because it adds to the filesize.

Re:HTTP isn't why the web is slow

[WaffleMonster]

The only reason you've given for HTTP/2.0 being worse is that it's not already an RFC.

It is worse because it is HOL'd and requires additional resources to manage state persistence for idle TCP channels. The other solutions leverage stateless cookies without speculative tradeoffs inherent with sitting on idle sessions. This is a BFD when your servicing thousands of concurrent requests.

SPDY and by extension HTTP/2.0 does not have head of line blocking issues. The requests are multiplexed, but tagged, and requests can be answered out of order.

*Everything* implemented over TCP has head of line blocking issues. This property is inherent in the definition of a stream which is what TCP implements. The only way around it is multiple independent streams. It does not matter how the protocol is structured or what it does as long as it is doing it within a single TCP stream.

Head of line blocking is really only an issue for dynamic content.

Why?

Pipelining all of your static resources through a single connection to a single subdomain is more efficient than multiple requests.

Even in the case where RFC7413 has not been deployed this isn't always true especially over low bandwidth/lossy links. If one stream has to eat RTT or worse RTO other streams can continue to transmit unimpeded. It is important to avoid cherry picking simulation results. Not all of them are positive.

Re:HTTP isn't why the web is slow

[omnichad]

There's a different type of HOL blocking specific to multiplexed HTTP pipelining (at the next highest protocol layer). If one resource is slow to load because of being dynamic, it can hold up the entire queue. That's not an issue with SPDY or HTTP/2.0.

My understanding is that your browser cookies and user agent string would be re-sent with every request using RFC7413. That's not small. And it can't handle POST requests safely, meaning fragmented protocols.

Re:HTTP isn't why the web is slow

[WaffleMonster]

There's a different type of HOL blocking specific to multiplexed HTTP pipelining (at the next highest protocol layer). If one resource is slow to load because of being dynamic, it can hold up the entire queue.

This makes little sense. HTTP/1.1 pipelining is only even possible if the size of content is known a-priori. Hard to imagine limited cases where you can know the size in advance before taking time to generate it.

I do agree there are multiple instances at multiple layers that can have the affect of stalling the pipeline.

My understanding is that your browser cookies and user agent string would be re-sent with every request using RFC7413. That's not small.

Its insignificant, what matters for senders is latency.

And it can't handle POST requests safely, meaning fragmented protocols.

I hope your kidding there are no useful transaction semantics defined for POST requests or any other HTTP verbs. Any assumption this is somehow safe today is wrong. It can only be made safe by application layer detection.

Re:HTTP isn't why the web is slow

[omnichad]

Multiplexing multiple streams within a single stream = Head of Line blocking. A problem that does not exist when using multiple independent streams are employed.

SPDY will allow later requests to be answered before the first one. You seem to be focusing on the aspect of re-using old stale connections. I'm talking about the many dozens of connections needed on the initial visit to a web site right now.

I hope your kidding there are no useful transaction semantics defined for POST requests or any other HTTP verbs. Any assumption this is somehow safe today is wrong. It can only be made safe by application layer detection.

The RFC itself says that it's vulnerable to replay attacks. Even more so than what's currently in use.

Re:HTTP isn't why the web is slow

[Chalnoth]

This is precisely why header compression is so useful.

Loading this page, for example, I see 93 separate requests, dozens of which are less than few kilobytes. And while there are a number of different domains, there are quite a few requests that share the same domain. I imagine that having only one connection per domain, instead of one connection per request, would reduce the number of connections by a factor of five or more (I'm not taking the time to look through and count nearly a hundred requests).

So yes, I do think that header compression is likely to be very useful. And combining header compression with allowing one connection for a batch of requests will give web developers quite a lot more flexibility in how they structure their websites.

Re:HTTP isn't why the web is slow

[WaffleMonster]

SPDY will allow later requests to be answered before the first one. You seem to be focusing on the aspect of re-using old stale connections. I'm talking about the many dozens of connections needed on the initial visit to a web site right now.

When I mention head of line blocking I am referring to the transmission of the overall stream of data transported via TCP. Whatever structure comprises SPDY the stream itself is subject to head-of-line blocking. Multiple unrelated assets within a related stream are at the mercy of the properties of that stream. Multiple unrelated parallel streams are able to operate *independently* of the other.

The problem occurs normally (bad luck, ICW) and especially with lossy networks such as a high latency wireless network you end up blocking for RTT or RTO.. during that time nothing is transmitted with SPDY. If instead parallel TCP streams are used remaining streams are able to continue transmission.

The RFC itself says that it's vulnerable to replay attacks.

Of course it absolutely is.

Even more so than what's currently in use.

To conduct a replay attack you need to be able to get a copy of the packet to replay it. If you can do this you can own the TCP channel. I don't know how things can get any worse. In either case with or without fast open adding security (e.g TLS) is often helpful.

Re:HTTP isn't why the web is slow

[greg1104]

To a lot of content providers, the ads are the important parts.

Ads anymore seem to have lot of dynamically generated content that isn't fully known until after the initial page is downloaded and some Javascript is run, perhaps even inspecting the local computer and its cookies. When that happens, it's impossible for loading the ads to happen concurrently with the main content. You're guaranteed a whole second round trip before the ad content is available.

Re:HTTP isn't why the web is slow

[mellon]

The anonymous hit piece is the Slashdot article, submitted by "anonymous."

Re:HTTP isn't why the web is slow

[Anonymous Coward]

Let's not bring politics into this.

Alarmist much?

[Anonymous Coward]

I think the submitter doesn't like Google.

First, 'SPDY was a very good prototype' followed by 'the most hideous of SPDY's warts removed' was summed up with '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.'.

Adopting and modifying a demonstrably working improvement for a standard is no cause for ire. Besides, this is the IETF we're talking about, be glad this is a modicum of improvement and not as blatant as something like this. http://arstechnica.com/security/2013/12/critics-nsa-agent-co-chairing-key-crypto-standards-body-should-be-removed/

Re:Alarmist much?

[omnichad]

With how much of HTML and other standards that Internet Explorer is responsible for, we should be glad that Google is having an influence.

Re:Alarmist much?

[Anonymous Coward]

spdy is exactly that. its so wired into one particular usage on one particular platform,
and so poorly specified that its basically impossible to publish as an ietf standard
as it stands. one standard benchmark is whether two people can go with the
spec into closets, write two different implementations, emerge and expect them
to interoperate. spdy definitely fails that test

its got a lot of great ideas in it

phk is exactly right.

start a group including the people google, go over everything, spend a year discussing it and make
a nice thing

Re:Alarmist much?

[Anonymous Coward]

>Adopting and modifying a demonstrably working improvement for a standard is no cause for ire.

I agree; that's why ECMA-376 / ISO 29500 was such a great idea!

(Mod funny if you get the joke.)

Re:Alarmist much?

[TheGratefulNet]

no, at this point (can't believe I'm saying this) - I trust MS more than I trust google.

I know what MS is up to and I can deal with them. they are not into wholesale spying and being *everywhere* on the web (can't avoid a google tracking site; everyone, now, uses them, sadly).

but google has depths of evil that we have not even seen yet. they have shown their true colors. they don't sell things TO US, they SELL US. that's a world of difference.

Re:Alarmist much?

[BlackHawk-666]

You can if you install Ghostery https://www.ghostery.com/en/

I also recently switched to Duck Duck Go, since I'm sick to death of all the spying and tracking my internet habits attract.

Include AdBlock of some sort, and you've just made the internet a much nicer place again (assuming you stay off Facebook and Twitter ;-> ).

Re:Alarmist much?

[Anonymous Coward]

(Mod funny if you get the joke.)

liek if you crie evry tiem

Re:Alarmist much?

[Anonymous Coward]

And how exactly will those tools help when half of my email communications is with people who use Gmail? Or businesses that use Google Apps as their back-end?

That freakin creepy company has set themself up perfectly to suck-up vast swatches of private communications.

Re:Alarmist much?

[mbkennel]

| First, 'SPDY was a very good prototype' followed by 'the most hideous of SPDY's warts removed' was summed up with 'the IETF can now claim relevance and victory by conceding practically every principle ever held dear

aka "not worshipping doe-eyed at my political whinging"

| in return for the privilege of rubber-stamping Google's initiative.'.

aka "they wanted to ship something that works, now"

Sure, it should be called 1.2 and not 2.0, but that's marketing BS anyway.

Microsoft doth protest too much?

[Anonymous Coward]

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

Re:Microsoft doth protest too much?

[Chrisq]

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

That's because you viewed it with an HTTP 2.0 compliant browser

Re:Microsoft doth protest too much?

[Anonymous Coward]

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

The author is a FreeBSD guy.

Re:Microsoft doth protest too much?

[dackroyd]

Er....the guy who wrote it is a heavy contributor to FreeBSD and developed Varnish.

Although he may have an agenda it's not because he's a shill for Microsoft.

Re:Microsoft doth protest too much?

[shutdown -p now]

Given that IE11 already supports SPDY, and the pre-release version of IE12 in Windows 10 supports the current HTTP/2.0 draft, that would be a very strange way to protest, and with no clear reason.

Re:Microsoft doth protest too much?

[shutdown -p now]

Oh, and apparently it's an article by Poul-Henning Kamp. You know, the guy who wrote like half of FreeBSD.

The IETF is irrelevant anyway

[bytesex]

With IPv6 the IETF has shown that they're on a long path toward oblivion. Too many cooks in the kitchen.

Re:The IETF is irrelevant anyway

[bigpat]

With IPv6 the IETF has shown that they're on a long path toward oblivion. Too many cooks in the kitchen.

We are all on the long path toward oblivion...the trick is to try and keep up.

Anonymous submitter plagiarised ACM Queue article

[Anonymous Coward]

This was written by Poul-Henning Kamp, and published in the ACM Queue.

Intosi

Article quoting a troll?

[mysidia]

Criticisms belong in the IETF discussion forum, but as long as the protocol is an improvement over HTTP/1, then this is progress. Sorry, PKH, about the Not Invented Here.

Yes, if the improvement to be made is great and Google or a 3rd party has already done enough work to have good results, then the standardization process should be expeditious, and if the IETF wishes to stay relevant, they should work to provide technologically better standards at a reasonable pace.

Re:Article quoting a troll?

[Carewolf]

PKH is a great man most of the time, but when he is wrong or fell overlooked, he is indistinguishable from a troll.

I like the fact IETF keeps this revision simple. The last thing we need is something overengineered that will never be implemented fully.

By Google, for Google

[Aethedor]

SPDY is a protocol by Google, for Google. Unless you are doing more or less the same as Google does, SPDY is not very relevant for you. Having multiple HTTP requests via a single connection via multiplexing is only relevant if all website content is located at one and the same server. This is not the case for many websites on the internet. Images, specially for advertisements, are often located at a different webserver. I've read about real live scenario's where SPDY only gave up to 4% speed increase. And for rich websites we already got something called websockets. I've done a lot of experimenting with smart caching, both static and CGI content. Specially with caching CGI output, you can reach a speed increase that no new protocol can ever achieve.

IETF only took SPDY as a base for HTTP/2.0 because they failed to do the job themselves. I personally don't have much faith in HTTP/2.0. Not that I think it will cripple the internet, but it will not bring an improvement to the internet that will be worth all the effort of implementing this new protocol.

Re:By Google, for Google

[Nemyst]

If SPDY is indeed focused on single-server sources like Google, then I'd say the opposite: SPDY is very relevant to the overwhelming majority of internet users. The vast majority of traffic is done on a select few sites such as Google, YouTube and Netflix. All of them benefit from that new protocol.

It won't necessarily help small websites and hosts, but let's not forget that a protocol isn't strictly about them.

Specific criticisms?

[Anonymous Coward]

Other than not wanting to follow Google, what exactly is being criticized? Are there specific issues? TimeTable seems awful fast so there's that but what are they proposing that's bad? Is this improvement or not? Incremental isn't bad is it?

Proposals and running code

[Lennie]

The Tao of IETF still mentions:
"We reject kings, presidents and voting. We believe in rough consensus and running code"
http://www.ietf.org/tao.html

Maybe it's just me, but might it apply here ?

Before the httpbis working group started looking at proposals for HTTP/2.0 SPDY was already implemented and deployed in the field by mutliple browser vendors, library builders for servers and several large websites. A bunch of research documents was written. And a protocol specification document draft existed. SPDY wasn't created in the open perse, but it was iterated with the help the community.

So the IETF WG let people suggest proposals:
http://trac.tools.ietf.org/wg/...

And then they voted.

SPDY got selected.

Also the SPDY draft was used as a basis for writing the new HTTP/2.0 draft.

Is anyone surprised ?

There might fundamental parts of the protocol which might have turned out differently if they would have gone through a open collaborative process.

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

I can see the appeal of rubberstamping what already exists.

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.

NAT

[Anonymous Coward]

If the protocol sucks, it'll go mostly unadopted.

See also: xhtml and arguably ipv6

If you think IPv6 sucks wait until you have to deal with two and three layers of (CG)NAT.

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:versus 20 years for IPv6. 2002 cutover to IPv6

[bigpat]

I think you could argue that IPv6 is a counter example to your argument. The parallel with http 2.0 could be that no matter what the features http 1.1 might be good enough for a very long time.

IPv6 perhaps came out 15 years too early because IPv4 deficiencies had quicker and easier workarounds than the switch to IPv6 and even some deficiencies like the limitation on address space was turned into a perceived benefit as more and more security concerns meant the boxes doing network address translation were now the boxes providing you with security. IPv4 is a good example of coming out with a good enough protocol given available resources and then the switching costs being too high in relationship to the benefits.

The Internet of Things was one of the driving motivations behind IPv6 long before it was called that. The idea that every electronic device would or could have a uniquely end to end addressable IPv6 address. That your refrigerator could communicate with you and the grocery store when it was out of milk. Or your car could communicate with your shop when it needed to schedule maintenance. And those things could all happen directly without reliance on centralized servers to mediate all that end to end communications.

But there have been a lot of contrary interests that are against that sort of direct communication because they want to be in the loop so they can aggregate metadata or mediate security or otherwise derive or provide add-on value and derive revenue from being the man in the middle. And unfortunately without an end to end IPv6 network that people can actually connect to and experience, then it is hard to envision the potential benefits to justify any push by people.

Given Google's traditional push for open standards it would be good to see end to end IPv6 be an option on Google Fiber and perhaps in collaboration with some Universities to demonstrate the benefits of having devices that can talk to one another across the Internet.

Re:versus 20 years for IPv6. 2002 cutover to IPv6

[Anonymous Coward]

True.

Most advancements are iterations of developments instead of sudden jump to some "perfect" point.

End-users might see it as the sudden deployment but development is in various stages.

Re:versus 20 years for IPv6. 2002 cutover to IPv6

[Anonymous Coward]

My favorite workaround for IPv6 is Cox's solution: their FAQ on when they will upgrade service to IPv6 has read "later in year $YEAR," where $YEAR was set to the current year, every year since the mid 2000's. It changed over to 2015 this year.

I suspect most places do about the same.

Re:versus 20 years for IPv6. 2002 cutover to IPv6

[unixisc]

Was it really the 'internet of things' that was required to drive the urgency? IPv4 has a max of not 4 billion, but actually 3.2 billion (if one does the math), and even w/ NAT, there were limitations since after each available address to the ISPs had been split among Class A/B/C customers, one would still need multiple layers of NAT. So IPv6 was always gonna be needed. I'd imagine that Mobile IP is what has driven the need for IPv6, since having several correspondent and mobile nodes was gonna be needed, and NAT here would be a genuine hurdle, while stateless autoconfiguration, while overkill w/ static networks, would certainly be appreciated here.

Re:versus 20 years for IPv6. 2002 cutover to IPv6

[WaffleMonster]

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?

I don't care if we're still using HTTP/1.0 a hundred years from now. IPv6 is actually needed to solve an actual problem and offers real benefit to users needing to directly communicate with their peers - especially those currently stuck behind carrier NATs lacking a global address of their own.

HTTP/2 isn't going to make anyone's online experience any better or faster. Even today with our quad core muti-ghz CPUs, GPUs, several GB ram, dozens mbits of bandwidth sites still take forever to load... the only thing that has changed instead of loading actual content more time is spent engaged in massive data collection and cross-domain spying. The problem that needs solving isn't technical it is political.

Re:versus 20 years for IPv6. 2002 cutover to IPv6

[bigpat]

Looking at IPv4 and a population growth chart. In 1981 when the IPv4 and RFC 791 were issued it would have been almost sufficient to give an IP address to every man woman and child on the planet. This at a time when rotary phones were still common and the idea of every man woman and child having their own computer was pretty extreme. Also the idea of keeping all those extra bytes in the routing tables would have been pretty wasteful considering it was a long term theoretical problem. Wasteful and expensive.

As for mobile routing needs, I would be interested to hear someone in the mobile space talk about how they are actually doing routing these days on LTE networks and the like. I wonder (and kinda doubt) if they are using IPv6 addresses for end to end communication or have simply done some sort of address translation between their mobile networks and the Internet.

Re:versus 20 years for IPv6. 2002 cutover to IPv6

[unixisc]

I believe the LTE spec requires IPv6: I doubt that there is any support for IPv4 in it. Which would make sense, since mobile usage would be a glutton for IP addresses - something that only IPv6 can provide

HTTP/1.1 is just fine

[allo]

Or at least something backward compatible, no stinking binary protocols.

Compression? Bandwidth is bigger and cheaper than ever. So why?
SPDY had in the first draft the nice feature, to require TLS, which was dropped, too. So not even this advantage stays there for spdy/http2

Re:HTTP/1.1 is just fine

[wonkey_monkey]

Compression? Bandwidth is bigger and cheaper than ever. So why?

Because it's faster whether or not you've saturated your bandwidth, for a start. Secondly, just because you're not paying for your internet traffic by the megabyte, doesn't mean no-one else is along the way.

Lastly - why not?

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 is just fine

[Anonymous Coward]

>no stinking binary protocols

What, your mind too feeble to handle it or something? Systems that I worked on get a TB per day of traffic which is hella expensive to get a pipe for yet some of the pinhead developers screamed like a sheep being castrated without anesthesia when the idea was floated to move away from SOAP to binary protocols to save on bandwidth and server (SOAP is hugely CPU intensive to parse) costs. (Compression, you say? LOL, guess what, that's hugely CPU intensive too.)

Only an idiot would use text based protocols for high transaction volume services if they didn't have to.

Re:HTTP/1.1 is just fine

[0123456]

There's a much, much easier way to reduce mobile bandwidth usage.

Block ads.
Block tracking Javascript.
Block all the crap, other than the actual content you're actually trying to download.

Re:HTTP/1.1 is just fine

[ADRA]

There's no reason to hate a protocol because its binary. That's just retarded since any protocol analyzer will be able to represent the data in a consice way for anyone who cares to know. The benefit of the new tech as I see it is this: You hit home page X, analytics has proven that 95% of users on page X go to page Y. Why not start batching out page pieces from Y early, so that when the user navigates to Y, it'll be there significantly faster. Seems like a win for me, as long as there's some semblence of security around cache saturation.

Re:HTTP/1.1 is just fine

[Anonymous Coward]

That actually caused an earlier IETF activity on "HTTP-NG" between July'97 and Dec'98 effort to revamp the HTTP protocol to die a silent death. (See http://www.w3.org/Protocols/HTTP-NG/Activity ). HTTP/1.1 was mostly good enough.

Re:HTTP/1.1 is just fine

[Todd Knarr]

Because none of that requires a new protocol? You can do that in HTTP/1.0, it's entirely a matter of client programming. And yes a protocol analyzer can decode a binary protocol for you, but it takes a bit of work to set them up to display one and only one request stream. A text-based protocol, meanwhile, can be dumped trivially at either end just by dumping the raw data to the console or a log file. Decoding and formatting a binary protocol takes quite a bit more code and adds work. As for bandwidth, the HTTP headers are a trivial amount of data compared to the content on modern web sites so gains from compressing the protocol headers are going to be minimal (content compression already exists in HTTP/1.1 and there's going to be little or no improvement there in the new protocol).

Re:HTTP/1.1 is just fine

[Todd Knarr]

Most of the bandwidth for modern web sites goes to content, not the HTTP headers. That's even with content compression, which is already part of HTTP/1.1. Reducing overhead by going to binary in the headers isn't going to reduce the bandwidth requirements by enough to notice, and comes at the cost of not being able to use very simple tools to do diagnosis and debugging (I've lost count of the number of times I was able to use telnet or openssl and copy-and-paste to show exactly what the problem with a server response was and demonstrate conclusively that we hadn't misformed the request nor botched parsing the response, having to use tools to encode and decode things would've led to the vendor questioning whether our tools were working right and then I'd've had to figure out how to prove the tools weren't misbehaving (telnet and openssl were widely-enough used that that wasn't a problem)).

Re:HTTP/1.1 is just fine

[Bengie]

Many web servers disable compression because it leaks data and has been a security threat for a while now. It has been mentioned before that IPSec implements compression, VPN implements compression, HTTP, and the files transferred over HTTP, like images. How many times does data need to be compressed? Once. We have too many layers recompression the same freaking data. Find a layer, do it all there.

Re:HTTP/1.1 is just fine

[ADRA]

Well, to my understanding, it isn't as simple as client programming alone. Even if you do open an out of band background streamer for backend pages, you still have a round-trip per resource, where you could, say pump images 1-100 in one push instead of a 'request-response * 100' loop along a persistent HTTP stream. Any more client-side processing, and you'd have to change the contract and let javascript parse and insert individual resulting blocks into the cache individually, which I don't believe is the case currently in browsers.

Just a casual search found this:
http://stackoverflow.com/quest...
As you can see, the 'fix' is to load each image from site individually instead of through a single bulk-fetch styled request which the server hosting the SPDY could then service. The other neat one is being able to fetch the host HTML page and get all its images / css streamed in one response. I hoep that the browsers can handle the responses streamed and handle them as yet incomplete page elements and not fetch them separately, because that would be truely awesome perf. / responsiveness.

Re:HTTP/1.1 is just fine

[DarkOx]

modern web sites goes to content

Sites maybe. Applications on the other hand stand to gain considerably. Watch some "modern" application sit there and make 100's of ajax requests for 14 lines of JSON and get back to me. For something web based trying to show any real-time information those headers can be 30% of the traffic.

As far as tooling I am not that worried, there will be plenty of accepted widely used tools available to dump web headers if the protocol went binary. I have never had anyone question if tcpdump is decoding ether frames properly. Once a few good libraries for C/Java/Ruby/Perl/Python are written stuff will just use them and all our tools will just get a point release.

Re:HTTP/1.1 is just fine

[Anonymous Coward]

You're probably using wireshark to look at the packets right now. Guess what, it already decodes the new ones, I don't see what more code and work *you* are going to add. The tooling was already done, but that obviously doesn't fit into the http/2 haters agenda.

Re:HTTP/1.1 is just fine

[Anonymous Coward]

The web wasn't made to create applications.
http://motherfuckingwebsite.com/

Re:HTTP/1.1 is just fine

[allo]

1) Who cares, if its faster, if you shave off like 20 bytes? With your 28k modem this was real time, but even with umts you do not notice the difference. Even with hundereds of connections (which do not work very good via umts for other reasons). And every little logo on a homepage makes you pay more than the 20 bytes saved in the http header.

Re:HTTP/1.1 is just fine

[allo]

we are talking about a few bytes, not even kilobytes.

With your argument you DO NOT want http/2 or spdy, because they push ressources you have not requested, like ads. You won't see them with your adblocker, but you still download them, because they are just sent.

Re:HTTP/1.1 is just fine

[allo]

if your site has 30% traffic for http-headers, you're doing it wrong. Have a look at websockets or server-sent events, if you need to get push data that often. even long polling will solve your problem.

Re:HTTP/1.1 is just fine

[allo]

> That's just retarded since any protocol analyzer will be able to represent the data in a consice way for anyone who cares to know
you are saying it. You need a protocol analyser. No more netcat or telnet, you will need stuff like tcpdump or wireshark or some special http2 tool to look into the data. The more complicated the tools for testing get, the harder debugging gets. So you actually can optimize less than before, because testing takes more time and efford.

Re:HTTP/1.1 is just fine

[Todd Knarr]

It's not just a matter of decoding the packets. The big problem is usually in separating out the packets for the connections from one specific client while ignoring the packets for all the other clients, and then assembling those packets into a coherent order so you can see individual requests and responses rather than just packets. That's fairly easy to do at each endpoint, much harder to do when just sniffing traffic in the middle. And of course the code to decode packets and assemble them into a transaction's more complex than the code to just append to a string and output that string to a file. Not everything has that kind of logging already built into it, and when I need to add it I'm usually pressed for time because it's a critical problem. tcpdump or wireshark will work, given enough effort, but I've too often seen them produce valid but deceptive results because while the filtering and selection and reporting were correct enough to look reasonable they weren't quite completely correct so the results were showing me something that didn't exactly match reality. Debugging dumps finally revealed the discrepancy, and we got the problems solved.

Re:HTTP/1.1 is just fine

[dave420]

It sounds like you are confusing "HTTP/2 sounds scary" with "I don't know how to use Wireshark". Understandable, really.

Poul-Henning Kamp's comment

[Anonymous Coward]

You might be interested in the full text of Poul-Henning Kamp article in full on ACM Queue:
http://queue.acm.org/detail.cfm?id=2716278

Re:Poul-Henning Kamp's comment

[robosmurf]

That was actually linked to in the post. Sadly, the post was remarkably unclear as to what it was actually referring to.

HTTP/1.1 good enough?

[codealot]

Two remarkable things about HTTP/1.1.

One, it remained a relatively simple protocol. Yes there are a lot of nuances around content negotiation, transfer encodings and such but at its core it is a simple, flexible and effective protocol to use, and can be implemented quite efficiently via persistent connections and pipelining. It was designed for response caching as well, and the CDN infrastructure is in place to make use of caching whenever possible.

Two, despite the simplicity of HTTP/1.1, a shocking number of implementations get it wrong or don't use it efficiently. Pipelining is disabled in many implementations due to compatibility concerns, and few applications can use it effectively. Many applications make excessive and unnecessary use of POST requests which are inherently not cacheable and result in many synchronous requests performed over high-latency connections. (SOAP was notorious for that.)

I'm skeptical that any protocol revision can improve on HTTP/1.1 sufficiently without making it harder to implement correctly than it already is.

If there were a broad initiative to begin to use the features of HTTP/1.1 properly, as they were designed, most of the shortcomings would vanish without the need for a new protocol.

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:HTTP/1.1 good enough?

[codealot]

Can't argue, and thank you for the interesting examples. I don't think HTTP is perfect, I was wondering out loud whether it is merely good enough.

Seems to me though that most of those problems arise from sloppy implementations (like you said, did they read the docs??) which supports my 2nd point. A perfect specification isn't going to prevent poor implementations.

Re:HTTP/1.1 good enough?

[Anonymous Coward]

H/2 is very hard to get right, but there is almost nothing you can do to simplify your implementation, so laziness will not be the cause of sloppy implementations here. Complexity will surely cause bugs though.

Willy

No surprise.

[Anonymous Coward]

No surprise. Google has been forcing their web tech down everyone's throats for years now, rather than playing ball. SPDY and MSE/EME/Dash are obviously mostly engineered to help Google's business first and foremost. They don't seem to care if they'll cause issues down the line, they just want to save money now. Oh well, at least it's not just NIH tech they're trying to ram down other's throats, like PPAPI and the Dart VM. Sometimes I think they just want to bloat and fragment the web up as much as possible to prove it's broken, so that they can swoop in and save it with their own replacement web stack.

Re:Anonymous submitter plagiarised ACM Queue artic

[robosmurf]

That article is actually linked to in the post. It's just one of the worst submissions I've seen for a while in making it hard to find the article it is referencing.

This entire summary is a troll

[MobyDisk]

This entire summary is devoid of content. It's just a long ranting insult with no valuable technical information at all. It could be talking about anything. This does not belong on Slashdot. With Slashdot these days I just want to downvote entire articles, or be able to edit the summary or something. HTTP 2.0 is probably a good topic to discuss, but not with a summary like this one.

Some will expect McDonald's new french fries to be a masterpiece, while others expect it to be a great example of design. Others will be cynical. There may be an assumption it is 'tastier.' Others will think it is 'greener.' Well the truth is yes, no ,yes, yes ,maybe, only sometimes, and definitely not.

Instead, how about something more like:

The IETF is preparing to ratify HTTP 2.0. This is the first significant update to the most widely-used protocol blah blah blah... However, the proposal is very polarizing because of ...

Re:This entire summary is a troll

[Anonymous Coward]

I think you are looking for Wikipedia. This is slashdot - I dont come here for "content" I come here for flame wars and techie spin on all things linkable.

Some specifics might be nice...

[sirwired]

What, precisely, is wrong with it?

"Because Google." Is not an answer.

heroic first steps against fuckery

[Anonymous Coward]

A number of companies looked at SPDY and saw the end to end encryption kept their fingers out.
So they formed the ATIS / Open Web Alliance.
These companies complain that they cannot
-- add value ( meaning "sell your eyeballs")
-- supply security (because they are locked out )
-- supply privacy (because they are locked out )
-- do your parent control for you ( let it be done at the device ! )
-- do traffic management and load balancing ( no throttling ! )

Now if we could only keep the government out.
( I suppose this is the 7th email needed to find something to hang me by.)

derp

[Anonymous Coward]

Posting anon to undo mistaken comment mod

What he's not telling you...

[Anonymous Coward]

What PHK is not telling you is that he fought, successfully, against mandatory encryption in HTTP/2.

Power and the IETF

[WaffleMonster]

The IETF like the UN is nothing more than meeting spaces for those with power to negotiate when it's in their best interests to do so.

I think it is unfortunate the principals IETF claims to stand for (technical merit over BS) are allowed to so easily be silenced by hand waving and procedural BS. Specifically it is laughable no appeal by anyone for any reason has ever succeeded within the IETF structure.

I've heard rumors this is not true yet having been subscribed to IETF announce for 10+ years and thumbing through appeals archive I could not find or recall a single example of any appeal ever succeeding. If you know otherwise I would love to hear about it.

Re:Power and the IETF

[Anonymous Coward]

Read PHK's full article and then decide who's doing the hand waving.

Accept IPv6 and build for it.

[Midnight Thunder]

If the protocol sucks, it'll go mostly unadopted.

See also: xhtml and arguably ipv6

I'll bite. While xhtml can be ignored rather safely, IPv6 not so much. IPv6 adoption is like the Y2K problem, but with no clear cut off date. We know we will run out of IPv4 addresses, but when depends on who you speak to or what your analysis is based on. As someone who takes care of infrastructure, I would rather start addressing IPv4 exhaustion problem with something other than double or tripple NATting, and provide a solution that is already working when others are screaming for lack of foresight.

To the people suggesting we could have taken an alternative approach to IPv6: any changes to IPv4 would break everything anyhow, so you might as well come up with a solution designed for the long term. NATs are tolerable up to a point, but once you double or n-Nat, then you are in a territory where doing things properly would have been better.

Certainly IPv6 probably creates new problems, but not ones that can't be solved with the proper tools. For example, you lose the apparent security of a NAT, but at that point Firewalls are already providing an alternative and capable solution.

Re:Accept IPv6 and build for it.

[unixisc]

I'd argue that IPv6 is a variable availability problem, unlike Y2K. Y2K had a single cutoff date for everybody - 1/1/2000, as opposed to the various dates that the RIRs are running out of. Which is why Asia and Europe were already there, and ARIN just got there last year.

It is a good idea to start designing in IPv6 networks and introducing them in organizations now before running out of IPv4 addresses. That way, services can make use of IPv6 addresses, while the IPv4 addresses can be just transition addresses b/w IPv6 and IPv4 points.

Even NAT, or more precisely, NAPT, is now available for IPv6 if people must have it: it eliminates many:1 mapping which was the main issue w/ IPv4, but has all the other advantages that NAT does.

Some specifics might be nice...

[Anonymous Coward]

You already know the specifics, because you have used google products before, and realized that their user design is shit because their products are not designed for users.