[dangrossman]

Why must HTTP 2.x be backwards compatible with 1.x? Should SSH have not been created because you can't talk to it with a telnet client? If a new protocol offers sufficient benefits, it would be worth having to make minor changes to apps to support both.

Cookies suck, from a technical and regulatory-compliance standpoint. Plus, I'll finally stop having to clear my cookies every month or so just to log in to my PayPal and American Express accounts. Both sites keep creating unique cookies on every login until there are so many that they pass their own web servers' max header length limits.

[comex]

> Why must HTTP 2.x be backwards compatible with 1.x?

Because the only benefit of removing cookies is a tiny bit of simplicity which could theoretically allow removing (a small amount of) code browsers will already have to keep around for probably at least a decade to support existing websites. If cookies are mostly unused by the time HTTP/3.x rolls around, we can talk...

> Cookies suck, from a technical

Agreed, but...

> and regulatory-compliance standpoint.

I don't understand this point. Surely the need for regulation of user tracking by websites doesn't depend on whether cookies or an equivalent mechanism are being used? If people start using Not Cookies(tm), they will be unregulated at first, but the law will be changed if the effect is the same.

Edit: Similarly, any protocol that gives a website a persistent identity token without its explicitly requesting one is a bad idea - cookies do provide a modicum of visibility to the user regarding who's tracking them. Not sure exactly what Kamp is proposing.

> Plus, I'll finally stop having to clear my cookies every month or so just to log in to my PayPal and American Express accounts. Both sites keep creating unique cookies on every login until there are so many that they pass their own web servers' max header length limits.

Hah, no you won't. I strongly suspect legacy codebases will remain on HTTP/1.1 approximately forever, at least if 2.0 is backwards incompatible.

[jasonwatkinspdx]

If you would bother to read the full thread as well as PHK's position proposal you'd see that removing cookies brings more than a tiny benefit. The overall flavor of his proposal is to reify a concept of session and by that eliminate redundant communication. At the same time we get substantial wins in security.

[comex]

You can add a concept of session without removing cookies, which are trivial to keep supporting since, as I mentioned, browsers will have to support cookies for legacy sites for a long time anyway.

I doubt the security argument amounts to much, considering that there are few sites with cookie-based vulnerabilities, it's long been trivially easy ($_SESSION in PHP) for any site to use identifiers as cookies, and many of the sites that are vulnerable are the kind of old-fashioned things that will never be upgraded anyway.

[jasonwatkinspdx]

Once you have a concept of a session unique nonce, cookies are needless. Browsers can implement a locally encrypted resumption store where the user entered entropy never touches the network to resume a session on the same machine. Resuming a session on a new machine could use 2 factor auth with fallback one time capabilities. That's big, doubly so given the clear historical trends in users ability to memorize entropy and the likelihood of hashed password database disclosure.

What you need to understand, is that we can get rid of cookies, live in a more secure world, and give up nothing. The only thing holding us back is unwillingness to understand the underlying issues and fear that we stand to lose something by advocating change.

On top of that, by standardizing on a nonce we avoid all cookie request overhead larger than the nonce, which is not trivial. Every mandatory request byte we save under MTU is huge.

[comex]

There is no difference between browsers implementing a locally encrypted resumption store for a nonce and for cookies (since again, most sites where security is important already use cookies purely as identifiers); nor does it affect whether sites will start requiring two factor for all logins. The two systems are equivalent except that one is simpler, but the (small amount of) complexity of cookies is not what's blocking these types of security measures.

I'm not saying additional login security isn't a good idea (although since local cookies tend to be compromised by malware running on the machine rather than offline attacks, it may not be that useful to encrypt them), and I'm not saying that avoiding cookies isn't a good idea, because cookies do tend to get bloated. But tying the two proposals together is unhelpful to both, because they're essentially orthogonal.

As for avoiding cookie request overhead, that is again something you can do by adding a standard nonce without actually removing the old mechanism; sites that want to be fast or have a standardized way to interact with HTTP routers, and most sites that use web frameworks, as the frameworks get updated, will use the new one. The only way removing cookies would help is if servers started translating cookies for legacy applications automatically, but I don't see that becoming prevalent because of document.cookie and related concerns.

edit: and again, breaking backwards compatibility is a great way to slow HTTP/2 adoption, not that it really matters unless it brings TLS to all sites along with it (but that's another story...)

[jasonwatkinspdx]

They are different because a server suggested resumable session nonce requires no form based authentication. User entered entropy never hits the wire. I do not know how to emphasize this point more strongly. Please read the research on trends in brute force and timing attacks vs human capacity for entropy memorization.

Evidence is clear: The majority of sites do not handle cookies securely. They do not handle user submitted entropy securely. Virtually no one supports 2 factor authorization (props to google on this point).

The scheme I am suggesting and the status quo are not equivalent as you suggest. I do agree that they are orthogonal, except at the point where we decide upon a standard.

I take it as a given that the status quo is unacceptable. If you disagree there's not much for us to discuss.

What I'd like to see is http/2 be a fresh design that is unwilling to sacrifice security. We can always assume http/1.1 or failback to it under negotiation. Because of that, there is no reason to burden a new standard with backwards comparability. Among the SPDY community you see this same perspective, often suggested as a tick/tock strategy where when version n+2 goes online version n+1 becomes backport only support and version n is abandoned.

[mbreese]

> and regulatory-compliance standpoint

One of the main reasons why people can't just turn off Cookies is because they are needed for session management. This makes it very difficult to just disable. If there was a dedicated session management method in HTTP/2.0 then that would remove a lot of the need for Cookies. Then they could be used for what they were intended (local persistent state). This would also give users better methods for managing them (or just disabling them).

[comex]

Eh... maybe eventually, once nothing uses cookies anymore (including existing HTTP sites). But surely this can be solved today by having browsers force cookies to expire with the session?

[newman314]

And that is what phk is advocating as part of his proposal. Cookies are the wrong tool to be used for session management.

[jfoutz]

you probably know this, but cookies are sent with every damn request the client makes. So it's a tax, It may be a small % of total traffic, but most of the time, it's useless.

[comex]

It's easy to work around this in a backwards compatible way, though, in a way that's applicable to more than just cookies - in requests after the first, only re-send headers that have changed.

Or just live with the hit while sites migrate to the new mechanism; I'm fine with it being considered a legacy thing.

[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.

[joahua]

I dunno - obviously different projects diverge on required backwards compatibility (Python 2/3?), but SSH isn't called Telnet v2.

For something as fundamental as HTTP the author argues changes need to be radical to drive adoption, but at the same time there's not necessarily wide-spread impetus to do so if the burden is too high. This is engineering on a 15 year time-scale, which I feel a little young (at 24) to well comprehend!

It's not just apps in the web-app sense, but user agents (all the way down to embedded systems) that would need changing to take advantage of the 'sufficient benefits'. That's a pretty massive undertaking.

[dangrossman]

HTTP 1.x will not disappear just because 2.x is available. Millions of people still run wifi networks on 802.11b; all those routers still keep on workin' even though 802.11a/g/n had 'sufficient benefits' that we build those into new hardware. There was no massive undertaking to replace all the routers in the world.

Nobody would have to change their old apps or hardware. Like SPDY, the availability of a new protocol supported by web browsers just means new stuff can optionally do things old stuff can't.