HTTP 2.0 First Draft Published

http://www.infoq.com/news/2012/11/http20-first-draft

by Garbage • 14 years ago

68 64 14 years ago

jgrahamc• 14 years ago

Personally (i.e. not speaking on behalf of my employer) I'm not terribly keen on SPDY being HTTP 2.0. It fixes HTTP/1.1 pipelining by adding a layer of binary complexity to a protocol that has succeeded by being simple and textual.

Also, it's a sort-of-layer because it really is dependent on details of HTTP (such as the existence of headers) to operate so it is not an independent layer. In networking I'm much happier when layers are independently specified.

Also, I think the implementation of header compression is poor because it uses a fixed dictionary that is based on current HTTP headers. There's no provision for negotiation of this going forward. It would be better if the compression dictionary were negotiated on session creation. Notice how the dictionary has been updated between standard drafts. Once it's in the standard updates will not be possible.

And SPDY requires TLS which means that if it were HTTP 2.0 it would require the deployment of certificates everywhere. That's an added expense for a web site operator. Unless SSL certificates are suddenly free and trivial to deploy then that would make HTTP 2.0 complex.

I would much rather see a proposal to change HTTP so that pipelining works, using textual headers and not require TLS.

kibwen• 14 years ago

Have you tried getting your voice heard in the standardization process?

tbrownaw6• 14 years ago

requires TLS which means that if it were HTTP 2.0 it would require the deployment of certificates everywhere. That's an added expense for a web site operator. Unless SSL certificates are suddenly free and trivial to deploy

Get the browser vendors to stop being idiots, and treat self-signed SSL connections as identical to plaintext connections.

Or even better get them to implement a notary model [ http://perspectives-project.org ] (as a default rather than an extension), that doesn't allow for a single insecure CA to break the security of the entire web.

revelation2• 14 years ago

I never thought about it from that angle. You are right, it makes no sense for browser vendors to display a big fat warning page because someone signed a certificate himself while they never let you know that 90% of the websites you use are transferred in plain-text over a wholly untrusted network.

zobzu7• 14 years ago

I work for some of the said vendor (and I'm being vague on purpose here). I took part of the discussion. I made the same point you did. People don't care. The argument was quickly dismissed by a "go get a cert for free at startssl". Seriously.

I think the Internet is a social change, and transforms people into idiots indeed. People in groups have always been more stupid than single persons. And Internet makes us all one freaking huge group of people.

Apparently if you don't share the popular idea you must be destroyed (you'll see this happen often in HN comments too).

Otherwise, here's another project, that works on the same principles as perspectives, but has a better back-end (albeit WAY less marketing) IMO http://web.monkeysphere.info/

tptacek13• 14 years ago

The first step towards an alternative to the multiple- single- points- of- failure CA model is already underway: it's Trevor Perrin and Moxie Marlinspike's TACK project (currently an Internet Draft). TACK allows sites to cache certificate pins, typically after first contact, so that any site on the Internet can have the same protection that Google's properties have today by virtue of the hardcoded pins in Chrome.

As Moxie Marlinspike has said, on HN even, TACK is a sensible and achievable first step towards a substrate that we can build notaries or other trust models on top of. It doesn't require years of study and consideration; it merely extends something that browser vendors already do for their preferred sites.

Meanwhile, browsers can't simply treat sites under self-signed certificates as normal plaintext HTTP sites. The user reached the site through an HTTPS URL, which promised them security. When the browser detects and warns about a self-signed certificate, it is telling the user "this site is lying about its security". The simple way to understand this: start by asking what a browser should do when the Citibank Online Banking Login presents a broken cert, and then ask how the browser should know when it's OK for a site to present as merely "not encrypted" (ie, HN login) and when it's not OK (ie, online banking). It can't. The browser has to assume that HTTPS sites with broken certificates are sensitive.

Remember also, the "broken certificate" case is exactly what happens when an attacker intercepts a TLS connection for a MITM attack.

paulsutter• 14 years ago

If you don't want to deal with certificates just keep using HTTP 1.1.

If you want the speed and security improvements of 2.0, certificates will get cheaper and easier to obtain. Most of the certificate authorities' costs are one-time (validating identity). Issuing subsequent certificates costs them nothing. Pricing will adjust accordingly with increased demand (and in some cases already has).

A fixed dictionary for header compression is a lot better than no compression dictionary. Negotiation would be added complexity/latency. Sure you could argue either way but it doesn't seem like a big deal.

Google has done a great job on SPDY. It's proven at scale and performs really well. Making it a standard is a great move.

fusiongyro• 14 years ago

Poul Henning-Kamp said many of the same things when this came up last time, and I agree with both of you.

https://www.varnish-cache.org/docs/trunk/phk/http20.html

IMO, a HTTP 2.0 standard based on SPDY is a small but meaningful illustration of the divergence from an idealistic egalitarianism to an oligarchy of a handful of huge organizations. The issues at stake here are basically monetary for Google and a few other companies. There's very little technical finesse here despite the added complexity, and certainly little to no reimagining or benefits to the vast majority of independent site operators or web developers.

salmanapk• 14 years ago

> Unless SSL certificates are suddenly free

Oh god why so many people dont know about StartSSL.com. They've been offering free SSL certificates since quite some time.

bickfordb• 14 years ago

It seems like it would be a lot simpler to fix the current pipelining infrastructure (already in the spec but not used?) and tag pipelined request/responses with request IDs.

sophacles• 14 years ago

I somewhat agree, however instead of making pipelining work in HTTP, they should remove it altogether, and focus the HTTP protocol to just the request response structure/headers. Then, create a second protocol - say HMWP (HTTP Multiplexed Wire Protocol) (not a real protocol, I just made that up) that focuses on pipelining, server-push, header compression, etc. This layering approach really feels more "internetty". It also would allow independent development in terms of network optimization and application handling.

This split would also help adress conflicts between Cache/Proxy/Balancer developers and Application developers.

mtgx• 14 years ago

My favorite part about it is that everything will be encrypted by default in the future.

deelowe• 14 years ago

And require SSL certs, which cost how much again? It's quite an expense for hobby sites, non-profits, and such.

selectnull2• 14 years ago

Like most (all?) digital products, the price of SSL certificates will converge to zero with higher usage. So mass adoption might be beneficial after all.

jarcoal• 14 years ago

It's about the same price as a domain unless you're doing wildcard certs.

jmillikin• 14 years ago

SSL certs are free: https://cert.startcom.org/

bvdbijl• 14 years ago

Free here: http://www.startssl.com/?app=1

pilif• 14 years ago

An even larger problem is IMHO that the two most widely deployed platforms world-wide (Windows XP and Android < 3) do not support SNI which forces you to use one IP address per domain.

So now we are moving to protocols that mandate SSL while at the same time we are quickly running out of IP addresses (and getting correctly working ipv6 on the two platforms in question is about as difficult as getting them to support SNI)

Firehed2• 14 years ago

$0; use StartSSL. They're in the trusted root CAs for Chrome and Firefox which are the only browsers that support SPDY so far (I think they're trusted in all major browsers, but I don't spend my day examining IE6's list of trusted CAs)

The actual cost is in requiring a dedicated IP per SSL site, which many hosts charge monthly for. Unless SNI is built into the spec (I browsed around briefly and didn't see a mention, other than a request for it being a requirement in a forum mid-2011), anyone intending to host multiple HTTP2.0/SPDY sites on the same box will need to buy a dedicated IP per domain. It's also something of a pain to add SNI support to an existing host, but so will adding the SPDY support.

NathanKP• 14 years ago

Does anyone else have any experience setting up SPDY on a web server? Since SPDY is already supported by Chrome and Firefox, I'd be interested in at least experimenting with it if there is an Apache or Nginx based solution which is stable enough to work in production. Of course I would also need to serve old style HTTP for those that are using a browser which doesn't support SPDY but if there is a way to serve SPDY to those who can support it I'm all for trying it out.

jolan• 14 years ago

There's mod_spdy for Apache 2.2 developed by Google employees:

http://code.google.com/p/mod-spdy/

And a spdy patch for nginx from one of the main nginx developers:

http://nginx.org/patches/spdy/

Wordpress and CloudFlare both use the nginx patch so it should be production ready.

I use mod_spdy and haven't had any problems.

HerraBRE• 14 years ago

I think it will be quite tragic if HTTP 2.0 ends up being a binary protocol. The discoverability and readability of the basic text based Internet was, in my opinion, one of its most fantastic qualities. It meant that as a young hacker I could just look at things and see how they work and then progress to learning and experimenting by writing very naive partial implementations of said protocols. I am not sure the bits saved justify the obfuscation of everything.

wildranter• 14 years ago

And here we go again, another design by committee to haunt us. If this piece of crap sticks we all will have to keep using HTTP 1.1 which by the way isn't that bad. First web sockets, and not this. Just great.

HTTP 2.0 First Draft Published

Related Stories