4 ms·

Never understood why the re-use of the "http://" http://" protocol, why not us "http2://" instead.

by carsonreinke 12y ago

wmf 12y ago
Because that would make it impossible to ever deploy HTTP/2.
- jessaustin 12y ago
  It didn't seem to stop https:// https:// Granted, I think it was overall a poor decision to introduce that scheme prefix as well. It's just that, many arguments against a new scheme prefix also applied in that case, and many arguments for that new scheme prefix would apply in this case.
parasubvert 12y ago
Because that would break every hyperlink on the web, and would create a separate web with content that existing clients or intermediaries would be excluded from. Much more evolvable to keep the wire protocol version orthogonal to URI. Further, technically speaking, the URL scheme has little to with the protocol used , it is merely a way of linking a hierarchical namespace to a spec (or more) that tells a developer how to resolve it. That means we have a lot of flexibility in terms of protocol (we don't even need a protocol defined in some cases - mailto: URIs for example).
- jimktrains2 12y ago
  > Because that would break every hyperlink on the web, Or you just run two servers (or a single server that speaks both), you know, like you'll have to for the next 30 years anyway. > and would create a separate web with content that existing clients or intermediaries would be excluded from. If you have an HTTP2-only site, aren't you doing that anyway? > Much more evolvable to keep the wire protocol version orthogonal to URI. > Further, the URL scheme has little to with the protocol used That first part, before the colon, is a protocol descriptor. It would be perfectly reasonable to change the protocol descriptor. What should have been done was use the Upgrade header (like websockets) or specify using SRV records.
  - wpietri 12y ago
    The only way an upgrade this big will happen is having a single server that speaks both, one that's a drop-in replacement. In which case, there's no point in breaking reverse compatibility with every HTTP-capable device on the planet just to make some fussbudgets happy that the URL is "more correct" in some obscure technical sense. As a counterexample, look at how long we've been working on IPv6. [1] We've been working on that for 20 years, and we're not even close. And all that aside, URLs aren't primarily API. They're UI. You don't go messing with a UI that billions of people use without a strong reason to do so. [1] http://www.ipv6.com/articles/general/timeline-of-ipv6.htm http://www.ipv6.com/articles/general/timeline-of-ipv6.htm
    - jimktrains2 12y ago
      > The only way an upgrade this big will happen is having a single server that speaks both, one that's a drop-in replacement. In which case, there's no point in breaking reverse compatibility with every HTTP-capable device on the planet just to make some fussbudgets happy that the URL is "more correct" in some obscure technical sense. Why would this preclude using a different protocol in the URI? > And all that aside, URLs aren't primarily API. They're UI. You don't go messing with a UI that billions of people use without a strong reason to do so. You mean UI that hidden by most browsers by default now?
      - wpietri 12y ago
        Hi! You get one round of point-sniping. After this, make a coherent point if you want a reply. It wouldn't preclude using a different protocol. It means that there's no point. If every HTTP/2 server is also an HTTP/1.1 server offering the same content then there is no practical need to distinguish the protocols. As to URL-hiding, you know that's controversial, and for good reason. Their theory is that a lot of people don't normally look, and that could even be true. Many always will, though. More importantly, that's not the only place that people use links. Every time they share one via email, for example. Every time they type one in from a magazine or the side of a bus or a flyer. Every time they cite one in a paper. Forcing those people suddenly include a protocol distinction that is meaningless to them and unimportant to the server involved would be a pointless waste. HTTP/2 is purely an under-the-hood improvement. They didn't have to change the URL for SPDY, and they don't have to change it for this.
patrickmcmanus 12y ago
The semantics of the URL aren't different - just the protocol version details. You didn't want different schemes for http/1.0 vs http/1.1 right? The URL still represents the same resource and if the server would like to inconsistently use different versions (perhaps because of inconsistent clusters or cdns) that's fine as long as the resource is consistent.
- carsonreinke 12y ago
  1.0/1.1 is so drastically different from 2
carsonreinke 12y ago
Found this related to it: http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/0981.html http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/...

Never understood why the re-use of the "http://" http://" protocol, why not us "http2://" instead.

wmf 12y ago

Because that would make it impossible to ever deploy HTTP/2.

jessaustin 12y ago
It didn't seem to stop https:// https:// Granted, I think it was overall a poor decision to introduce that scheme prefix as well. It's just that, many arguments against a new scheme prefix also applied in that case, and many arguments for that new scheme prefix would apply in this case.

parasubvert 12y ago

Because that would break every hyperlink on the web, and would create a separate web with content that existing clients or intermediaries would be excluded from. Much more evolvable to keep the wire protocol version orthogonal to URI. Further, technically speaking, the URL scheme has little to with the protocol used , it is merely a way of linking a hierarchical namespace to a spec (or more) that tells a developer how to resolve it. That means we have a lot of flexibility in terms of protocol (we don't even need a protocol defined in some cases - mailto: URIs for example).

jimktrains2 12y ago
> Because that would break every hyperlink on the web, Or you just run two servers (or a single server that speaks both), you know, like you'll have to for the next 30 years anyway. > and would create a separate web with content that existing clients or intermediaries would be excluded from. If you have an HTTP2-only site, aren't you doing that anyway? > Much more evolvable to keep the wire protocol version orthogonal to URI. > Further, the URL scheme has little to with the protocol used That first part, before the colon, is a protocol descriptor. It would be perfectly reasonable to change the protocol descriptor. What should have been done was use the Upgrade header (like websockets) or specify using SRV records.
- wpietri 12y ago
  The only way an upgrade this big will happen is having a single server that speaks both, one that's a drop-in replacement. In which case, there's no point in breaking reverse compatibility with every HTTP-capable device on the planet just to make some fussbudgets happy that the URL is "more correct" in some obscure technical sense. As a counterexample, look at how long we've been working on IPv6. [1] We've been working on that for 20 years, and we're not even close. And all that aside, URLs aren't primarily API. They're UI. You don't go messing with a UI that billions of people use without a strong reason to do so. [1] http://www.ipv6.com/articles/general/timeline-of-ipv6.htm http://www.ipv6.com/articles/general/timeline-of-ipv6.htm
  - jimktrains2 12y ago
    > The only way an upgrade this big will happen is having a single server that speaks both, one that's a drop-in replacement. In which case, there's no point in breaking reverse compatibility with every HTTP-capable device on the planet just to make some fussbudgets happy that the URL is "more correct" in some obscure technical sense. Why would this preclude using a different protocol in the URI? > And all that aside, URLs aren't primarily API. They're UI. You don't go messing with a UI that billions of people use without a strong reason to do so. You mean UI that hidden by most browsers by default now?
    - wpietri 12y ago
      Hi! You get one round of point-sniping. After this, make a coherent point if you want a reply. It wouldn't preclude using a different protocol. It means that there's no point. If every HTTP/2 server is also an HTTP/1.1 server offering the same content then there is no practical need to distinguish the protocols. As to URL-hiding, you know that's controversial, and for good reason. Their theory is that a lot of people don't normally look, and that could even be true. Many always will, though. More importantly, that's not the only place that people use links. Every time they share one via email, for example. Every time they type one in from a magazine or the side of a bus or a flyer. Every time they cite one in a paper. Forcing those people suddenly include a protocol distinction that is meaningless to them and unimportant to the server involved would be a pointless waste. HTTP/2 is purely an under-the-hood improvement. They didn't have to change the URL for SPDY, and they don't have to change it for this.

patrickmcmanus 12y ago

The semantics of the URL aren't different - just the protocol version details. You didn't want different schemes for http/1.0 vs http/1.1 right? The URL still represents the same resource and if the server would like to inconsistently use different versions (perhaps because of inconsistent clusters or cdns) that's fine as long as the resource is consistent.

carsonreinke 12y ago
1.0/1.1 is so drastically different from 2

carsonreinke 12y ago

Found this related to it: http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/0981.html http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/...