3 ms·

> Not usually one to get behind speculation, but if one were to provide an educated guess, what does everyone think about the timeline of switchover from 1.1 to

> Not usually one to get behind speculation, but if one were to provide an educated guess, what does everyone think about the timeline of switchover from 1.1 to 2.0? 1 year? 5 years? Try never. Too much embedded devices out there which 1. won't get updated, 2. doesn't have enough storage for a crypto-stack and 3. doesn't have the computational power to process a crypto-stack should it even be updated to have one. Internet-standards are published, approved and then stays forever. You will realistically need to support all versions until "the end of time", or at least the end of the internet as we know it.

mankyd 12y ago
> Try never. Well, it depends on how you define "switchover". Enabling HTTP/2 doesn't necessarily mean turning HTTP/1.1 off.
wwarren 12y ago
Isn't HTTP/2 totally backwards compatible though? So those devices won't ever need to be updated ... in theory
- vertex-four 12y ago
  No. HTTP/2 is an entirely separate protocol from HTTP/1.1. Any client, therefore, will have to have both HTTP/1.1 and HTTP/2 protocol stacks. What HTTP/2 does define is a way for the client to say "I support HTTP/2" and the server to say "Sure, talk HTTP/2 to me" in a way that allows the client to fall back to HTTP/1.1 if the server doesn't know about HTTP/2.
  - deleted 12y ago
    [deleted]
  - gsnedders 12y ago
    It's not entirely separate, as the abstract of it says: "This specification is an alternative to, but does not obsolete, the HTTP/1.1 message syntax. HTTP's existing semantics remain unchanged."
    - vertex-four 12y ago
      Indeed, the point of that message is essentially "HTTP/2 is an entirely new protocol, you can support HTTP/1.1 or HTTP/2 or both, but they have nothing to do with each other".
      - gsnedders 12y ago
        Well, it means all your handling of messages is the same — once you have built your object/struct/whatever of the message (from the over-the-wire syntax), you can hand it off to pre-existing code that expects HTTP/1 messages fine. Most HTTP/2 implementations share a fair bit of code with co-existing HTTP/1 ones. You don't need to redo all your caching support and handling of HTTP caching headers, you don't need to redo any support for content negotiation you have, etc.
      - dragonwriter 12y ago
        > but they have nothing to do with each other The fact that HTTP/2 retains HTTP/1.1's message semantics, as the note points out, means that they have a lot to do with each other, and that implementations will be able to share much (probably most) of their core logic. This is important -- it means that if you implement HTTP/1.1, you've done a lot of the work of implementing HTTP/2, and vice versa.
dragonwriter 12y ago
> You will realistically need to support all versions until "the end of time", or at least the end of the internet as we know it. Or until all the old devices have reached the end of their useful life; the internet hasn't been in general use that long, and what seems like "forever" looking back on a few decades of history may not going forward. And, anyway, even that's only true if the particular thing you are building is the kind of general purpose infrastructure that needs to support everything that might talk some form of HTTP anywhere, no matter how old or limited-purpose that device is. Plenty of things people actually build don't have that requirement.

mankyd 12y ago

> Try never. Well, it depends on how you define "switchover". Enabling HTTP/2 doesn't necessarily mean turning HTTP/1.1 off.

wwarren 12y ago

Isn't HTTP/2 totally backwards compatible though? So those devices won't ever need to be updated ... in theory

vertex-four 12y ago
No. HTTP/2 is an entirely separate protocol from HTTP/1.1. Any client, therefore, will have to have both HTTP/1.1 and HTTP/2 protocol stacks. What HTTP/2 does define is a way for the client to say "I support HTTP/2" and the server to say "Sure, talk HTTP/2 to me" in a way that allows the client to fall back to HTTP/1.1 if the server doesn't know about HTTP/2.
- deleted 12y ago
  [deleted]
- gsnedders 12y ago
  It's not entirely separate, as the abstract of it says: "This specification is an alternative to, but does not obsolete, the HTTP/1.1 message syntax. HTTP's existing semantics remain unchanged."
  - vertex-four 12y ago
    Indeed, the point of that message is essentially "HTTP/2 is an entirely new protocol, you can support HTTP/1.1 or HTTP/2 or both, but they have nothing to do with each other".
    - gsnedders 12y ago
      Well, it means all your handling of messages is the same — once you have built your object/struct/whatever of the message (from the over-the-wire syntax), you can hand it off to pre-existing code that expects HTTP/1 messages fine. Most HTTP/2 implementations share a fair bit of code with co-existing HTTP/1 ones. You don't need to redo all your caching support and handling of HTTP caching headers, you don't need to redo any support for content negotiation you have, etc.
    - dragonwriter 12y ago
      > but they have nothing to do with each other The fact that HTTP/2 retains HTTP/1.1's message semantics, as the note points out, means that they have a lot to do with each other, and that implementations will be able to share much (probably most) of their core logic. This is important -- it means that if you implement HTTP/1.1, you've done a lot of the work of implementing HTTP/2, and vice versa.

dragonwriter 12y ago

> You will realistically need to support all versions until "the end of time", or at least the end of the internet as we know it. Or until all the old devices have reached the end of their useful life; the internet hasn't been in general use that long, and what seems like "forever" looking back on a few decades of history may not going forward. And, anyway, even that's only true if the particular thing you are building is the kind of general purpose infrastructure that needs to support everything that might talk some form of HTTP anywhere, no matter how old or limited-purpose that device is. Plenty of things people actually build don't have that requirement.