[mbreese]

HTTP/2.0 doesn't have to be backwards compatible at all. In fact, I see the future protocol switch being pretty simple. There will be new HTTP/2.0 servers and HTTP/1.1 legacy servers. The clients will speak either language, but 2.0 servers will be faster. Eventually clients will let the user say if they want to talk to 1.1 servers at all.

The initial line will remain the same, except for the version:

    GET /page HTTP/2.0
    *** extra 2.0 headers/request ***

If the server speaks 2.0, it will just carry on. If it doesn't, the server will return a 505 and the client will resubmit the request:

    GET /page HTTP/2.0
    505 HTTP Version Not Supported
    GET /page HTTP/1.1
    *** 1.1 headers / request ***

There is no reason the protocols must to be backwards compatible past the first line. Hell, 2.0 could even be binary after that first line. So, while they don't have to be compatible, they can still coexist.

[rdsubhas]

It's not about "server speaking HTTP/2.0". Its about "application speaking HTTP/2.0".

Every web app today is married with $COOKIE statements. The whole problem for me as a web developer is that existing applications will have to be rewritten just to run on top of a cookie-less HTTP/2.0 protocol.

SPDY, despite all its architectural problems, has taken off in a huge way (even Facebook is implementing it) just because applications don't have to be rewritten. You could just install mod_spdy in apache and be done with it. From the view of the web developer, these kind of breaking changes just makes life more painful.

[mbreese]

Of course this about the server speaking HTTP/2.0. We are talking about a potential client-server protocol upgrade. The fact that millions of applications are written to the 1.1 spec shouldn't be a factor in working on the 2.0 spec.

I believe that HTTP/2.0 will necessarily require applications to be rewritten. Or at least frameworks will need to be updated in order to take advantage of the new features. And you can expect some pain when other features are taken away. If there is a push to make cookies more 'optional', you can expect that clients will start to let users block cookies entirely. Would you rather your application kinda work for people but not those on 2.0 browsers? No, of course not, you'd rather it work for everyone. So why try to run a 1.1 webapp across the 2.0 protocol.

If you are hard-coding $COOKIE statements in your code, you aren't writing it to a sufficient abstraction to be able to survive a future major version jump. But there's nothing wrong with that. Major version jumps in a protocol are pretty rare, and your code will still work just fine as a 1.1 webapp.

If you're writing applications that expect to be dealing with HTTP requests, then of course you'll have to rewrite applications to run on a major version upgrade of a protocol. This is what will be expected. Major version updates shouldn't necessarily be backwards compatible, and that's the main argument of the post. If the update is marginal, there will be nothing to drive adoption of 2.0 over 1.1.

What I was trying to point out was that, (hypothetically) if HTTP/2.0 isn't backwards compatible, that doesn't mean that HTTP/1.1 and 2.0 applications couldn't co-exist on the same site (or even the same server).

Plus, let's remember, this is all hypothetical - we are still trying to figure out the goals of HTTP/2.0.

[Tuna-Fish]

An important consideration is that forcing the first line on the HTTP2.0 server can actually really hurt it. I mostly agree with Kamp's considerations on HTTP routers, and not having all data necessary for routing at fixed offsets in the packet instantly makes their jobs harder.

The very least, you want the server-provided identity header to be before all the variable-length fields, because in normal situations, most high-throughput servers will be able to fully route their traffic on it alone.

[mbreese]

No, I agree that HTTP doesn't make things easier on HTTP routers. Variable length headers that have to be parsed does nothing for speed.

However, this is the method that HTTP has defined for version upgrades, so if you want to muck around with the first line, you lose the ability to co-exist with HTTP/1.1 on the same port.

And I really doubt that they'll want to switch ports for HTTP/2.0.

One possible method would be forcing width padding of the request-path and Host headers. This would potentially make it possible to use fixed offsets. But this strikes me as inelegant.