4 ms·

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.