3 ms·

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

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.
      - jimktrains2 12y ago
        > 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. But not ever HTTP/1.1 server will be an HTTP/2 server; that's my point. > As to URL-hiding, you know that's controversial, and for good reason. I know; I hat it. I brought it up because obviously most people don't seem to care enough about it that we should overload a schema specifier for the sake of aestetics that don't matter. > 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. OK? some people cite ftp links. I'm not seeing your point. > Forcing those people suddenly include a protocol distinction that is meaningless to them and unimportant to the server involved would be a pointless waste. So we shouldn't use ftp:// or smb:// anymore? I don't get your point, because people are already used to non-http schemas. > HTTP/2 is purely an under-the-hood improvement. I mean you could say the same thing if all your assets were served over ftp and the browser rendered them as it does http. HTTP/2 is _fundamentally_ different than HTTP/1.1.
- parasubvert 12y ago
  > 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. The point is not that origin servers need to be upgraded, it's that clients and intermediaries should not be forced to upgrade. That means the actual content of the web (HTML pages) should not require revision to support the wire protocol upgrade, especially considering HTTP has an upgrade mechanism already built in. There's almost no benefit that I can see to require a new scheme, and tremendous downside. > That first part, before the colon, is a protocol descriptor. It would be perfectly reasonable to change the protocol descriptor. Actually, if you look at the specs, the first part is a scheme identifier, not a protocol identifier. There's a big difference. Schemes point you here: http://www.iana.org/assignments/uri-schemes/uri-schemes.xhtml http://www.iana.org/assignments/uri-schemes/uri-schemes.xhtm... And then you look up the spec for how to interpret and/or resolve the rest of the URI. That may or may not involve a mapping to a wire protocol (e.g. the "about" scheme, or the "geo" scheme).
  - jimktrains2 12y ago
    > The point is not that origin servers need to be upgraded, it's that clients and intermediaries should not be forced to upgrade. And HTTP2 doesn't require these upgrades? Clients and caching servers all need to support the new protocol. > That means the actual content of the web (HTML pages) should not require revision to support the wire protocol upgrade, Why would they? I'm not sure why the content matters in this discussion. > And then you look up the spec for how to interpret and/or resolve the rest of the URI. That may or may not involve a mapping to a wire protocol (e.g. the "about" scheme, or the "geo" scheme). OK, fair enough. How does this change my point though? HTTP vs HTTP2 requires a change in how the client "interpret[s] and/or resolve the rest of the URI."

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.
    - jimktrains2 12y ago
      > 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. But not ever HTTP/1.1 server will be an HTTP/2 server; that's my point. > As to URL-hiding, you know that's controversial, and for good reason. I know; I hat it. I brought it up because obviously most people don't seem to care enough about it that we should overload a schema specifier for the sake of aestetics that don't matter. > 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. OK? some people cite ftp links. I'm not seeing your point. > Forcing those people suddenly include a protocol distinction that is meaningless to them and unimportant to the server involved would be a pointless waste. So we shouldn't use ftp:// or smb:// anymore? I don't get your point, because people are already used to non-http schemas. > HTTP/2 is purely an under-the-hood improvement. I mean you could say the same thing if all your assets were served over ftp and the browser rendered them as it does http. HTTP/2 is _fundamentally_ different than HTTP/1.1.
parasubvert 12y ago
> 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. The point is not that origin servers need to be upgraded, it's that clients and intermediaries should not be forced to upgrade. That means the actual content of the web (HTML pages) should not require revision to support the wire protocol upgrade, especially considering HTTP has an upgrade mechanism already built in. There's almost no benefit that I can see to require a new scheme, and tremendous downside. > That first part, before the colon, is a protocol descriptor. It would be perfectly reasonable to change the protocol descriptor. Actually, if you look at the specs, the first part is a scheme identifier, not a protocol identifier. There's a big difference. Schemes point you here: http://www.iana.org/assignments/uri-schemes/uri-schemes.xhtml http://www.iana.org/assignments/uri-schemes/uri-schemes.xhtm... And then you look up the spec for how to interpret and/or resolve the rest of the URI. That may or may not involve a mapping to a wire protocol (e.g. the "about" scheme, or the "geo" scheme).
- jimktrains2 12y ago
  > The point is not that origin servers need to be upgraded, it's that clients and intermediaries should not be forced to upgrade. And HTTP2 doesn't require these upgrades? Clients and caching servers all need to support the new protocol. > That means the actual content of the web (HTML pages) should not require revision to support the wire protocol upgrade, Why would they? I'm not sure why the content matters in this discussion. > And then you look up the spec for how to interpret and/or resolve the rest of the URI. That may or may not involve a mapping to a wire protocol (e.g. the "about" scheme, or the "geo" scheme). OK, fair enough. How does this change my point though? HTTP vs HTTP2 requires a change in how the client "interpret[s] and/or resolve the rest of the URI."