HTTP/2.0 – Please admit defeat

http://lists.w3.org/Archives/Public/ietf-http-wg/2014AprJun/0815.html

by hungryblank • 12 years ago

323 108 12 years ago

lists.w3.org

kolev2• 12 years ago

Well, SPDY might be a "prototype", but it's solving real problems today - I care less if it's perfect or not, if it solves all problems or not, as long as it's easy to implement, has a decent footprint, and offers significant improvements over HTTP/1.1. An imperfect working prototype is better than a perfect blueprint that materializes in distant future where problems and environment can differ greatly.

adamtulinius• 12 years ago

Well, according to this mail from the Jetty-team, it doesn't seem like http/2.0 is easy to implement at all: http://lists.w3.org/Archives/Public/ietf-http-wg/2014AprJun/...

Furthermore, if http/3.0 is already being discussed, why not just skip http/2.0 entirely, and live with the current http/1.1+SPDY situation until the work towards a new standard for http is actually done?

canadev• 12 years ago

What does "LC" mean in that post?

kolev2• 12 years ago

Wait 5 more years? No thanks!

justincormack3• 12 years ago

But you can continue to use it even if it is not the standard as it has widespread support.

prohor• 12 years ago

But then you need to support 1.0, 1.1, 2.0 and 3.0. I'd rather wait a bit to avoid need to support yet another version. I can bet every new version of HTTP will cost millions of dollars across the industry. It is not agile where you just drop in a new increment. This is the base everybody need to support then and you won't be able to stop support in foreseeable future.

jacquesm• 12 years ago

I can bet every new version of HTTP will cost millions of dollars across the industry.

That would be a fairly easy bet, but I doubt anybody would take the other side. My own estimate at rolling out a major HTTP protocol revision across the industry would be in the 100's of millions. Take into account that we have approximately 750 million web sites and 3 billion clients.

stormbrew2• 12 years ago

I am so glad there is at least one prominent name advocating this line, because I feel like this quote from another IETF discussion is becoming more and more relevant:

Is there an IETF process in place for "The work we're doing would harm the Internet so maybe we should stop?" - http://www.ietf.org/mail-archive/web/trans/current/msg00238....

HTTP/2.0 has been rammed through much faster than is reasonable for the next revision of the bedrock of the web. It was always clearly a single-bid tender for ideas, with the call for proposals geared towards SPDY and the timeline too short for any reasonable possibility of a competitive idea to come up.

There has never been any good reason that SPDY could not co-evolve with HTTP as it had already been doing quite successfully. If it was truly the next-step it would have been clear soon enough. All jamming it through to HTTP/2.0 does is create a barrier for entry for similar co-evolved ideas to come about and compete on even footing.

youngtaff7• 12 years ago

PHK has always been skeptical of HTTP/2 & SPDY

He wants radical change in the protocol but when given the opportunity submitted a (by his own admission) half baked proposal - there's also the question of what a protocol like HTTP/2 means for his product.

Although HTTP/2 started from SPDY it has evolved, and in different ways e.g. see the framing comments from the thread the OP links to.

We need a better protocol for the web now, yes we could wait around longer for more discussion but where did that get us with HTTP/1.1 - I'd be quite happy if IETF had just adopted SPDY lock, stock and barrel (and no I don't work for Google)

stormbrew2• 12 years ago

I'm aware that he's always been skeptical, I saw his posts as my own excitement over the idea of HTTP/2.0 died on the vine from being subscribed to the WG mailing list.

There has never and will never be a point in time where we don't need "a better protocol for the web now." The issue is that canonization was unnecessary, adoption of spdy has been progressing fine without it. And HTTP/2 diverging significantly from spdy does not inspire confidence, either. Rather it just reminds of a famous xkcd [1]and again begs the question of whether trying to turn spdy into http/2 even manages to achieve any of the goals the process was setting out for.

The whole thing just seems like a big fat SNAFU.

[1] http://xkcd.com/927/

taspeotis• 12 years ago

Related [1]:

    Wired: How has your thinking about design changed over the past decades?

    Brooks: When I first wrote The Mythical Man-Month in 1975, I counseled
    programmers to “throw the first version away,” then build a second one.
    By the 20th-anniversary edition, I realized that constant incremental
    iteration is a far sounder approach. You build a quick prototype and
    get it in front of users to see what they do with it. You will always
    be surprised.

[1] http://www.wired.com/2010/07/ff_fred_brooks/

orkoden• 12 years ago

This is true for application software you write. Standards work differently.

bostik• 12 years ago

I am not sure how well that applies to a protocol that is supposed to be codified in every single browser, web server and utility library in the world. The iteration cycle will be slow, and improvements can not happen overnight.

Now, if the name was something like HTTP/1.8-alpha it might be a different thing. At least then it wouldn't carry the label of the "next big thing for everyone". It's sad, but names (and branding) do matter. Forcing a known-broken implementation upon the world is not exactly good engineering.

twic• 12 years ago

WebSockets went through a series of iteration cycles like this. It wasn't entirely smooth sailing, but it seems to have worked out.

wmf• 12 years ago

Google can iterate on SPDY and QUIC by just releasing new versions of Chrome, which is where all the knowledge behind HTTP 2.0 came from.

aaron6952• 12 years ago

I'm surprised that people still believe the Mythical Man-Month. As mentioned it was written almost 40 years ago.

It was revolutionary at the time but people have moved on and found many improvements to the original and also outright mistakes.

(As the author seems to have acknowledged when releasing a new improved iteration of his book.)

adamlett• 12 years ago

I'm surprised that people still believe the Mythical Man-Month. As mentioned it was written almost 40 years ago.

That hardly means that what it has to teach isn't still valid. Admittedly, I've only read a few chapters in it, but the central point that throwing more man power at a late project only serves to make it later, is at least as relevant today as when the book was first published.

It was revolutionary at the time but people have moved on and found many improvements to the original and also outright mistakes.

Could you be more specific?

(As the author seems to have acknowledged when releasing a new improved iteration of his book.)

So, do your points above refer only to the first edition of the book then?

jerf• 12 years ago

The impressive thing about the Mythical Man-Month isn't that, 40 years later, it is accurate in every detail and utterly relevant to your life. The impressive thing is that 40 years later, it still has a substantial amount of stuff that is accurate and relevant to your life, and that 40 years later, people still get wrong what we knew was wrong 40 years ago.

I would also accept an interpretation where that's an indictment on the field.

mattgreenrocks2• 12 years ago

Mistakes? Improvements? Please share.

Few books in our industry have been more prescient.

raverbashing• 12 years ago

This

And I'm very afraid of the following phrase:

"we found out that there are numerous hard problems that SPDY doesn't even get close to solving, and that we will need to make some simplifications in the evolved HTTP concept if we ever want to solve them."

This usually means "ending up with a protocol that has a lot of corner cases and a lot of backward-compatible crap or maybe some half-baked stuff that was left because of some feature that nobody uses"

I am very skeptic of protocols/standards that are born from a committee (take a look at telephony protocols/standards if you doubt me)

chc• 12 years ago

How does the word "simplifications" denote "corner cases and stuff that was left because of some feature nobody uses"? That's the opposite of how the message sounded to me. I thought it meant they would somehow jettison corner cases and pet features in order to reduce scope.

jballanc3• 12 years ago

I think this (http://lists.w3.org/Archives/Public/ietf-http-wg/2014AprJun/...) follow-up makes a valid point:

In the old days we had different protocols for different use cases. We had FTP and SSH and various protocols for RPC. Placing all our networking needs over HTTP was driven by the ubiquitous availability of HTTP stacks, and the need to circumvent firewalls. I don’t believe a single protocol can be optimal in all scenarios. So I believe we should work on the one where the pain is most obvious - the web - and avoid trying to solve everybody else’s problem.

If we're not careful, we're just going to end up cycling back around again and find ourselves 20 years in the past.

That said, I do think to some extent "that ship has sailed". The future of network programming seems like it will be "TCP --> HTTP -(upgraded connection)-> WebSockets --> actual application layer protocol". See, for example, STOMP over WebSockets. While it is annoying that this implies we've added a layer to the model, it's hard to argue with the real-world portability/ease of development that this all has enabled.

pjc502• 12 years ago

The importance of firewall punching can't be overstated. There are plenty of end users in workplaces or on other people's wifi who find that all outgoing ports other than 80 and 443 are blocked. Yes, this is incredibly stupid, but they're not going to do anything about it.

skrebbel2• 12 years ago

So we tunnel everything through 80/443, and then proxies are going to deep packet inspect that, and selectively block some over-http protocols, so we're going to tunnel stuff through a more innocuous looking protocol over HTTP, and tunnel through the tunnel through the tunnel through the tunnel.

I propose OpenVPN/SOCKS/WebSocket/HTTP/TCP/IP as the new de-facto standard connection protocol. Maybe we can FTP through that VPN connection some time, please wait while I cook up a JavaScript FTP/OpenVPN/SOCKS/WebSocket/HTTP/TCP/IP client.

josteink2• 12 years ago

So what you're saying is that since incompetent firewall admins have blocked all applications except the web and no amount of reason can convince them to do otherwise, all applications of the future should be tunnelled through HTTP.

And thus naturally HTTP must be made to accommodate for all those applications.

You may think that makes sense, but you don't create something as long-lasting as internet-scale architecture based on hacks around incompetence.

Besides, if that's the path we're walking, DPI-based firewall with HTTP-level application firewalling will become the new norm, and we've gotten nowhere further. Except we now have a even bigger mess to work with.

While the OSI-model may be going a bit over board for some aspects, making all future application-protocols be a squashed through HTTP is madness. This thinking is of the same quality and mindset as of PHP developers.

andybalholm2• 12 years ago

On the other hand, there are firewall administrators who do extensive filtering on ports 80 and 443 and allow other outgoing traffic by default. We get pretty ticked off when some thermostat, credit card machine, or postage meter decides to send its bizarre and undocumented data stream over port 80 or 443 in the name of firewall compatibility and therefore becomes incompatible with our firewall. (Yes, we can put in exceptions for those machines' IP addresses, but if they didn't try to use HTTP ports, they would Just Work.)

simon_vetter• 12 years ago

Until a big enough player decides to use something else.

Case in point: 5223/tcp, used by Apple's Push Notification service (amongst other things). Push notifications not being delivered to so many networks made their users angry and tech support calls (and costs) boom, and had soon 5223/tcp unblocked, even on free, non-encrypted, coffee-shop wifi networks.

I understand that most developers just choose to roll with it these days, but I really believe that putting everything atop of 443/tcp because of clueless/incompetent sysadmins is a huge mistake.

Keeping protocol stacks small, efficient and secure should be a design goal.

peterwwillis• 12 years ago

Here's why I think firewall punching is stupid and should not be supported.

IP addresses are logical numbers used to communicate with a host. In order to make it easier for humans to know what host to communicate with, DNS records were created to be able to easily communicate with a particular host.

In addition to figuring out what host we want to communicate with we need a way to specify what application we want to use. So service names were created and assigned to a static list of application port numbers. Two of these application service names are "http" and "https", which each provide a different application protocol.

We've built so many things that depend on these two application protocols that developers have finally outgrown what the protocols are capable of. But to get support for a new protocol is "hard". You have to do three things to successfully roll out a new application protocol:

1. Write a server for it and make people want to use it, 2. Write a client for it and get users to want to use it, 3. Get network administrators to open up their firewalls to support it.

Sadly, many developers are playing a cat-and-mouse game with network administrators. They want their applications to be used by anyone, anywhere, automatically. So they employ tricks to get their content past network administrators, like re-using the same application service names used by protocols which are ubiquitously supported throughout worldwide networks.

But this just creates an arms race with network admins. For example, mandating strong encryption to use a service means a network admin traditionally can't restrict what kind of applications work over it. So in order to fight their users subverting their approved applications policies, more and more organizations are doing SSL inspection by injecting CA certs into their employees' computers to block unauthorized applications.

Fighting network admins is a losing game, and does not benefit the users of your applications, or the developers. Instead of hiding more features and overlaying protocols, it would be more productive to create protocols that use their own service names and provide their own functionality and let users demand it be supported by the network admins. This is how all popular application services have been adopted over the years and provides the best quality of service to everyone involved.

icebraining• 12 years ago

The future of network programming seems like it will be "TCP --> HTTP -(upgraded connection)-> WebSockets --> actual application layer protocol".

It's not like WebSockets runs "over" HTTP, it just uses an HTTP-like handshake; besides that, it's just a simple framing protocol over TCP.

That's why you can use a simple proxy to "websocket-ify" applications that use plain-old raw TCP connections.

jballanc3• 12 years ago

Right, that's why I said we're adding one layer (not two).

Still, if TCP is the transport layer, and HTTP/SMTP/etc. are the application layer, then what do we call WebSockets when we implement an application layer protocol on top of it? The application compatibility layer?

In the past we had operating systems with network stacks and shared libraries for working with application protocols. Now we have browsers with network stacks and JavaScript libraries for working with application protocols. Wasn't it just a few days ago that someone was proposing an OS that would do just enough to boot a browser, and then let the browser handle most of the "traditional" operating system tasks? How long before we see a proposal for "lowering" WebSocket connections to the TCP layer?

This is what I mean when I say that we risk finding ourselves 20 years in the past. HTTP isn't ubiquitous because it is better. It's better because it is ubiquitous. If we don't pay attention to why things like WebSockets are easier to use today than raw TCP, then history will repeat itself.

Negitivefrags• 12 years ago

it's just a simple framing protocol over TCP

Websockets is ridiculous for this reason.

It has a stream abstraction (Websocket API) over a packet based protocol (Websocket Protocol) on top of streaming protocol (TCP) on top a packet protocol (IP).

This shit has to stop.

We had everything we needed. Websockets should have just been exposing regular sockets to the browser.

I don't buy the HTTP proxy argument.

chacham15• 12 years ago

I think that one of the best things about HTTP/1.0 (and to a lesser extent 1.1) is its simplicity. The reason, to me, that that simplicity is so vital is because it has fostered large amounts of innovation.

maaaats• 12 years ago

What an awful way to try and get a point across. An aggressive tone and negative words baked into every other sentence, making the statements very loaded. There's probably a lot of missing context from viewing only this link, though.

lerouxb• 12 years ago

I think it makes sense to take the time to get it right. Every version of HTTP will effectively have to be supported by just about every server and client forever or otherwise the web will break.

An incredible aspect of the web is that Tim Berners-Lee's first website back at CERN still works in modern browsers. Same with things like basically the entire Geocities archive.

When it gets to core infrastructure like HTTP you can't just iterate quickly and expect the entire internet to constantly upgrade along with you.

What works for early stage lean startups won't work here.

zhyder• 12 years ago

Interesting response from the WG chair: http://lists.w3.org/Archives/Public/ietf-http-wg/2014AprJun/...

An aside: I find it odd how HN users jump to agreement when a link to a single mailing-list message is posted, ignoring other discussion on the thread. I think it's because the UI makes it hard to see the rest of the conversation (unlike -say- the comments UI on HN itself)

higherpurpose• 12 years ago

I'm in favor of dumping HTTP/S and using a faster and more secure (by default) Transport protocol altogether. Post Snowden revelations we should be focusing our energy on that, rather than continuing to hack around this old protocol to make it faster and more secure.

marios• 12 years ago

MinimaLT [1] comes to mind. Minimal latency through better security sounds very appealing, especially when it's not a marketint trick but a paper signed by people like DJB.

The way I see it though, is not only to have a protocol, but how to get adoption. Especially when you're talking about network protocols, you need rock solid stacks in all major operating systems which is not an easy feat to accomplish.

[1] http://cr.yp.to/tcpip/minimalt-20130522.pdf

brianpgordon• 12 years ago

I haven't been following the development of HTTP/2.0. What are the most egregious "warts and mistakes" in SPDY?

fredliu5• 12 years ago

Mobile is one of them, although OP's arguments are valid as well. (http://conferences.sigcomm.org/co-next/2013/program/p303.pdf) Also, among many other things: every thing over SSL. Single Connection. Also, less of a technical problem, but as many already mentioned, too complicated as compared to plain text human readable HTTP 1.x

zobzu• 12 years ago

also ssl everywhere without authentication by default. ie slower, encrypted, but not actually safe.

justincormack3• 12 years ago

There is another interesting thread about internet of things http://lists.w3.org/Archives/Public/ietf-http-wg/2014AprJun/...

"So it looks like HTTP 2 really needs (at least) two different profiles, one for web hosting/web browser users ("HTTP 2 is web scale!") and one for HTTP- as-a-substrate users. The latter should have (or more accurately should not have) multiple streams and multiplexing, flow control, priorities, reprioritisation and dependencies, mandatory payload compression, most types of header compression, and many others."

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

"First and foremost, it needs to be recognized that HTTP/2 has been designed from the start to primarily meet the needs of a very specific grouping of high volume web properties and browser implementations. There is very little evidence that ubiquitous use of the protocol is even a secondary consideration -- in fact, the "they can just keep using HTTP/1.1" mantra has been repeated quite often throughout many of the discussions here on this, usually as a way of brushing aside many of the concerns that have been raised. So be it. It's clear at this point that HTTP/2 is on a specific fixed path forward and that, for the kinds of use cases required by IoT, alternatives will need to be pursued."

youngtaff7• 12 years ago

Pretty sure every ecommerce site will benefit from deploying HTTP/2

(although their tendency to fill sites full of third party components may reduce some of its benefits)

justincormack3• 12 years ago

Well the complexity makes it hard to build a performant server.

https://groups.google.com/forum/#!searchin/mechanical-sympat...

fredliu5• 12 years ago

Not exactly sure under what specific scenarios "every e-commerce site" will be running, but if HTTP/2 == SPDY, it's not looking good on mobile: http://conferences.sigcomm.org/co-next/2013/program/p303.pdf <== TLDR: current SPDY implementation has negative impact on Mobile performance. SPDY sucks on mobile is sort of a known fact, but this paper shows solid evidence that it's true.

sebcat• 12 years ago

It should be noted that the sender of this e-mail is Poul-Henning Kamp, known among other things for another e-mail from back in the day (relatively speaking): http://bikeshed.com/

quasque2• 12 years ago

Would it be accurate to suggest that the rushing of Google's SPDY, as HTTP/2.0, through IETF standardisation is roughly equivalent to the situation a few years ago when Microsoft pushed Office Open XML through as an ECMA standard? Or is that just a huge mischaracterisation?

marcosdumay2• 12 years ago

That's a huge mischaracterization.

There are a few different implementations of SPDY, and a clear use case where it applies. Also, it's a clear standard, made for being used.

What's happening here is that there is a group of very active people that create most of the software we use on the web, and have a use case they want to support. At the same time, there are lots and lots of people that are not as active, with a huge amount of use cases that will be hindered, but since they are not active, they have very little voice.

quasque2• 12 years ago

Thanks for the explanation, I haven't been following the progress of SPDY so I'm not familiar with the detail. What use cases would be hindered by this new standard?

mantrax5• 12 years ago

You know what we need, we need to pick one of those people and give 'em one day to invent HTTP/2.0 and it'll be a better spec compared to letting them all "decide" together by nerd-fighting each other into eternity.

No standard is perfect, but the worst standard is no standard.

Make up your fucking mind already.

gioele• 12 years ago

To put the comment and its author in context, Poul-Henning Kamp is the main developer of Varnish, a widely used high-performance standard-compliant HTTP cache.

PHK has experience of HTTP both from the server point of view (the main job of Varnish is acting as a fast HTTP server) and from client point of view (Varnish acts as client to the slow upstream HTTP servers).

As a side note, he also refrained for years from adding TLS support to Varnish after his review of OpenSSL and SSL in general (see https://www.varnish-cache.org/docs/trunk/phk/ssl.html ).

ruben_varnish• 12 years ago

Good one. More context on the ideas and proposal Poul-Henning has put on the table: http://phk.freebsd.dk/words/httpbis.html

cwp• 12 years ago

Sounds to me like the real problem is lack of IP addresses, and the best strategy would be to hold off on updating HTTP and work on IPv6 ubiquity first. I can see why Google went a different route, but we don't all have to follow.

phkamp7• 12 years ago

I'm here in case you want to ask me anything.

Poul-Henning

acdha• 12 years ago

For those of us who don't follow this discussion in detail, why are you thinking the protocol needs to be scrapped outright rather than modified? Is it simply the complexity Greg Wilkins mentioned or are you really thinking about bigger philosophical changes like dropping cookies as we know them? Dropping HPACK seems like a great engineering call but that seems like a relatively minor change rather than starting over.

http://lists.w3.org/Archives/Public/ietf-http-wg/2014AprJun/... made me wonder what your standby plan would be – let the people who really need to care about performance use SPDY until a more ambitious HTTP 2.0 stabilizes? One of the concerns I have is that many people want performance now and it seems like HTTP 2.0 might turn into the next XHTML if it takes too long to emerge.

phkamp7• 12 years ago

I think the fundamental problem with HTTP/2.0 is that it is a inadequate rush job for no good reason.

If you really want to gain performance for instance, the way to go is to get rid of the enormous overhead of cookies, to replace the verbose but almost content-free User-Agent header and so on.

Likewise, wrapping all the small blue 'f' icons and their associated tracking icons in TLS/SSL does not improve privacy on the net in any meaningful way.

But the entire focus has been to rush out a gold-plated version of SPDY, rather than to actually solve these "deep" problems in HTTP.

Similarly: Rather than accept that getting firewalls fixed will take a bit of time, everything gets tunneled through port 80/443, with all the interop trouble that will cause.

And instead working with the SCTP people on getting a better transport protocol than TCP ? Stick it all into the HTTP protocol.

Nobody seems to have heard the expression "Festina Lente" in this WG.

gerardvanvooren• 12 years ago

What do you think about the http/0.2 proposal? http://http02.cat-v.org/

Of course we don't live in Plan-9's 9P world, and I don't think we will ever live in that world, but if you think about it, it makes a lot more sense. In every aspect. 9P could make lots of troubled / tied (think XML standard such as WebDAV) / historical standards (FTP, NFS) obsolete. It is sane, simple, fast and secure because it is just a stream of bytes, displayed as a filesystem. There is no need for tons of librarycode. And http/0.2 could be backwards compatible. With http/0.2 you could also have session id. Besides that, with mounting httpfs there is no absolute need for a browser. You could use the standard commandline tools, altough the browser is gonna be used in almost any case.

All I wanna say is that I agree with your ideas. HTTP/2 is probably gonna have a long breath, so thinking it over, and start from scratch would be a good idea IMO. With 9P it could be a real dealmaker.

themgt• 12 years ago

A much better comment to link to would have the grandparent, by Greg Wilkins from Jetty, who gives a lot more substance and context to the debate: http://lists.w3.org/Archives/Public/ietf-http-wg/2014AprJun/...

It does seem a little shocking that the WG chair is proposing last call while still there's serious discussion of things like dropping HPACK.

josteink2• 12 years ago

Just like they admitted that XHTML 2 was a mistake and scraped it, I feel they should do the same with this nonsense.

Nothing about spdy or http2.0 sparks any sort of confidence with regard to proper robust protocol design, keeping things simple nor properly separating concerns.

haberman• 12 years ago

It's funny that you mention XHTML 2, because I think it demonstrates the opposite of what you are arguing.

XHTML 2 is a lot more like what PHK is proposing: an attempt to "rethink" HTML, come up with something simpler, revolutionary rather than evolutionary, "The Right Thing." It was an attempt to reinvent the space from first principles, and had lots of ideas that were theoretically good but unproven at large scale.

When that went nowhere, the world settled on HTML5: evolutionary, incremental, and based on standardizing existing practice. Much less sexy, but more useful in practice.

There is a time and a place for bold new ideas, but a standards body designing v2 of a protocol isn't it. Standards are for codifying proven ideas. When standards bodies try to innovate you end up with XHTML, VRML, P3P, SPARQL, etc.

dragonwriter• 12 years ago

Just like they admitted that XHTML 2 was a mistake and scraped it

But "they" (the W3C) didn't do that when people were just complaining about issues with the XHTML 2.0 approach, they did it after a competing approach was developed via an extensive, multi-year process through an outside group (WHATWG), and even then only that after a short period when both approaches were the focus of official W3C working groups.

They didn't adopt a "this is limited, lets throw it away and start over" approach as the original article here calls for with regard to HTTP/2.0.

alexnewman• 12 years ago

It's not perfect so start over. Seems like the definition of why v2 is always so hard.

HTTP/2.0 – Please admit defeat

Related Stories