On Tue, Aug 16, 2016 at 03:24:14PM -0700, Josh Triplett wrote: > > But if we had a real full-duplex connection over https, I think there > > would be no reason for git:// to continue existing (we'd probably keep > > ssh as it's a useful protocol for authentication, though). > > Agreed. > > Using ALPN wouldn't actually end up using HTTPS; it would negotiate with > the server and end up connected directly to a git program speaking an > arbitrary protocol over TLS. Many web servers already support ALPN to > negotiate HTTP/2, so this seems plausible. It sounds like that would lose one of the nice properties of git-over-http, which is that it works through arbitrary proxies (for some people on restricted networks, they are stuck going through a company-wide proxy, and neither git:// nor ssh are options in the first place). Maybe the world is heading in the direction of supporting ALPN everywhere, but I suspect we'll be dealing with older proxies for a while. > Another alternative would be to define a framing for a full-duplex > git-upload-pack connection inside a single HTTP/2 connection; HTTP/2 > already effectively allows full-duplex asynchronous conversations. This has some of the same problem as above, though I'd bet on HTTP/2 support becoming mainstream more quickly. I'm not very well educated on HTTP/2, but my understanding is that it _doesn't_ just provide a full-duplex asynchronous connection out of the box. You get "server push", but that is not quite the same thing. So I'm not sure if we can make something work on top of those building blocks, and if we do, how well it would fare with standard components like proxies in the middle. -Peff -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html