4 ms·

> 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

> 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.
- carsonreinke 12y ago
  It should be spdy:// in my opinion.

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.
carsonreinke 12y ago
It should be spdy:// in my opinion.