4 ms·

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

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.

joahua 14y ago
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 14y ago
  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.
comex 14y ago
> 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.
- jfoutz 14y ago
  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 14y ago
    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 14y ago
  > 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 14y ago
    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 14y ago
    And that is what phk is advocating as part of his proposal. Cookies are the wrong tool to be used for session management.
- jasonwatkinspdx 14y ago
  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.
mbreese 14y ago
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 14y ago
  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 14y ago
    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.

joahua 14y ago

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 14y ago
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.

comex 14y ago

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

jfoutz 14y ago
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 14y ago
  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 14y ago
> 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 14y ago
  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 14y ago
  And that is what phk is advocating as part of his proposal. Cookies are the wrong tool to be used for session management.
jasonwatkinspdx 14y ago
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.

mbreese 14y ago

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 14y ago
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 14y ago
  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.