upload-pack/ls-remote: showing non-HEAD symbolic refs?

upload-pack/ls-remote: showing non-HEAD symbolic refs?

[Josh Triplett]

Commit 5e7dcad771cb873e278a0571b46910d7c32e2f6c in September 2013 added
support to upload-pack to show the symbolic target of non-HEAD symbolic
refs.  However, commit d007dbf7d6d647dbcf0f357545f43f36dec46f3b in
November 2013 reverted that, because it used a capability to transmit
the information, and capabilities have a limited size (limited by the
pkt-line format which can't send lines longer than 64k) and can't
transmit an arbitrary number of symrefs.

(Incidentally, couldn't the same problem occur if the HEAD points to a
long enough path to exceed 64k?  Unlikely to arise in practice, but
theoretically possible for a constructed repository.  Not a major
problem at the moment, since send-pack doesn't seem to support
*sending* symbolic refs, but it would become a problem given any
mechanism to send symbolic refs to the server.)

I'd like to be able to see the targets of non-HEAD symbolic refs for a
repository (symbolic refs under refs/).  I'm interested in extending
upload-pack to expose those somehow.  What seems like a sensible format
to do so?

Would it make sense to advertise a new capability for symbolic ref
targets, which would allow the client to send back a dedicated request
for the targets of all symrefs?

- Josh Triplett

Re: upload-pack/ls-remote: showing non-HEAD symbolic refs?

[Jeff King]

On Tue, Aug 16, 2016 at 09:18:39AM -0700, Josh Triplett wrote:

> Commit 5e7dcad771cb873e278a0571b46910d7c32e2f6c in September 2013 added
> support to upload-pack to show the symbolic target of non-HEAD symbolic
> refs.  However, commit d007dbf7d6d647dbcf0f357545f43f36dec46f3b in
> November 2013 reverted that, because it used a capability to transmit
> the information, and capabilities have a limited size (limited by the
> pkt-line format which can't send lines longer than 64k) and can't
> transmit an arbitrary number of symrefs.
> 
> (Incidentally, couldn't the same problem occur if the HEAD points to a
> long enough path to exceed 64k?

Yes. But it's a lot easier to say "your 64k symref is ridiculous; don't
do that" than it is to say "oh, you happened to have a lot of symrefs in
your repository, so we overflowed and failed".

Besides which, the whole protocol cannot handle refnames larger than
64k, so it's not a new problem.

> I'd like to be able to see the targets of non-HEAD symbolic refs for a
> repository (symbolic refs under refs/).  I'm interested in extending
> upload-pack to expose those somehow.  What seems like a sensible format
> to do so?
> 
> Would it make sense to advertise a new capability for symbolic ref
> targets, which would allow the client to send back a dedicated request
> for the targets of all symrefs?

It will definitely require a new capability. You cannot just send a
"\0symref=..." trailer after each ref, because older clients treat
multiple "\0" trailers as overwriting one another (so it essentially
overwrites the old capabilities).

Sadly you cannot use a capability to fix that, because all of this
happens before the client agrees to any capabilities (you can find
discussion of a "v2" protocol on the list which solves this, but it's
sort of languishing in the design phase).

So you are stuck introducing a new phase into the protocol, which is
probably rather tricky (especially with the http protocol, which is very
sensitive to extra round-trips). I guess the least-invasive way would be
to communicate the desires in the "want" phase, and then have the server
dump it out with the packfile. Like:

  - server claims "I support symref-wants" in the capability phase

  - during the negotiation phase, in addition to "want" and "have", the
    client may send "symref <ref>" packets. Probably <ref> should be a
    wildcard to avoid having to ask about each ref individually.

  - before outputting the packfile in the final phase, if any "symref"
    wants were sent by the client, the server dumps a list of "symref
    <from> <to>" packets, followed by a flush packet.

That should Just Work over the existing http protocol without requiring
an extra request.

-Peff

Re: upload-pack/ls-remote: showing non-HEAD symbolic refs?

[Josh Triplett]

On Tue, Aug 16, 2016 at 12:31:45PM -0400, Jeff King wrote:
> On Tue, Aug 16, 2016 at 09:18:39AM -0700, Josh Triplett wrote:
> 
> > Commit 5e7dcad771cb873e278a0571b46910d7c32e2f6c in September 2013 added
> > support to upload-pack to show the symbolic target of non-HEAD symbolic
> > refs.  However, commit d007dbf7d6d647dbcf0f357545f43f36dec46f3b in
> > November 2013 reverted that, because it used a capability to transmit
> > the information, and capabilities have a limited size (limited by the
> > pkt-line format which can't send lines longer than 64k) and can't
> > transmit an arbitrary number of symrefs.
> > 
> > (Incidentally, couldn't the same problem occur if the HEAD points to a
> > long enough path to exceed 64k?
> 
> Yes. But it's a lot easier to say "your 64k symref is ridiculous; don't
> do that" than it is to say "oh, you happened to have a lot of symrefs in
> your repository, so we overflowed and failed".
> 
> Besides which, the whole protocol cannot handle refnames larger than
> 64k, so it's not a new problem.

Absolutely agreed.  I mentioned it only because if a server provided any
mechanism to send it symbolic ref targets, this could lead to a
situation where you could push a repository that you could not
subsequently pull.  Depending on the protocols involved, that could
potentially require manual admin intervention, or could even result in a
DoS.

Not something that can arise with git itself, as send-pack/receive-pack
doesn't support sending symbolic ref targets, but I could imagine a
server doing so to allow setting HEAD.

> > I'd like to be able to see the targets of non-HEAD symbolic refs for a
> > repository (symbolic refs under refs/).  I'm interested in extending
> > upload-pack to expose those somehow.  What seems like a sensible format
> > to do so?
> > 
> > Would it make sense to advertise a new capability for symbolic ref
> > targets, which would allow the client to send back a dedicated request
> > for the targets of all symrefs?
> 
> It will definitely require a new capability. You cannot just send a
> "\0symref=..." trailer after each ref, because older clients treat
> multiple "\0" trailers as overwriting one another (so it essentially
> overwrites the old capabilities).
> 
> Sadly you cannot use a capability to fix that, because all of this
> happens before the client agrees to any capabilities (you can find
> discussion of a "v2" protocol on the list which solves this, but it's
> sort of languishing in the design phase).

As a potential 1.1 version, which could work in a backward-compatible
way with existing servers and no additional round-trip: what if, in the
smart HTTP protocol, the client advertised client capabilities with an
additional HTTP header (e.g.  "Git-Client-Caps: symrefs othershiny
featurenames"?  git-http-backend could then pass those capabilities to
git-upload-pack (--client-caps='...'), which could take them into
account in the initial response?

That wouldn't work as a single-pass approach for SSH, since the client
can't know if the server's upload-pack supports --client-caps, but it
would work for the smart HTTP protocol.

> So you are stuck introducing a new phase into the protocol, which is
> probably rather tricky (especially with the http protocol, which is very
> sensitive to extra round-trips). I guess the least-invasive way would be
> to communicate the desires in the "want" phase, and then have the server
> dump it out with the packfile. Like:
> 
>   - server claims "I support symref-wants" in the capability phase
> 
>   - during the negotiation phase, in addition to "want" and "have", the
>     client may send "symref <ref>" packets. Probably <ref> should be a
>     wildcard to avoid having to ask about each ref individually.
> 
>   - before outputting the packfile in the final phase, if any "symref"
>     wants were sent by the client, the server dumps a list of "symref
>     <from> <to>" packets, followed by a flush packet.
> 
> That should Just Work over the existing http protocol without requiring
> an extra request.

It'd require one extra request for git ls-remote, which normally doesn't
need the second round-trip, but that still seems reasonable.

Re: upload-pack/ls-remote: showing non-HEAD symbolic refs?

[Jeff King]

On Tue, Aug 16, 2016 at 10:34:44AM -0700, Josh Triplett wrote:

> > Sadly you cannot use a capability to fix that, because all of this
> > happens before the client agrees to any capabilities (you can find
> > discussion of a "v2" protocol on the list which solves this, but it's
> > sort of languishing in the design phase).
> 
> As a potential 1.1 version, which could work in a backward-compatible
> way with existing servers and no additional round-trip: what if, in the
> smart HTTP protocol, the client advertised client capabilities with an
> additional HTTP header (e.g.  "Git-Client-Caps: symrefs othershiny
> featurenames"?  git-http-backend could then pass those capabilities to
> git-upload-pack (--client-caps='...'), which could take them into
> account in the initial response?
> 
> That wouldn't work as a single-pass approach for SSH, since the client
> can't know if the server's upload-pack supports --client-caps, but it
> would work for the smart HTTP protocol.

You can dig up the discussion on the list under the name "protocol v2",
but basically yes, that approach has been considered. It's a little
gross just because it leaves other protocols behind http (and it is not
necessarily a good idea to push people into http, because it has some
fundamental drawbacks over the other protocols because of its
half-duplex nature).

> > That should Just Work over the existing http protocol without requiring
> > an extra request.
> 
> It'd require one extra request for git ls-remote, which normally doesn't
> need the second round-trip, but that still seems reasonable.

Good point. I don't think there's an easy way around that short of v2 or
v1.1 that you mention above. I agree it's probably reasonable, though.

-Peff

Re: upload-pack/ls-remote: showing non-HEAD symbolic refs?

[Stefan Beller]

On Tue, Aug 16, 2016 at 11:28 AM, Jeff King <peff@peff.net> wrote:
> On Tue, Aug 16, 2016 at 10:34:44AM -0700, Josh Triplett wrote:
>
>> > Sadly you cannot use a capability to fix that, because all of this
>> > happens before the client agrees to any capabilities (you can find
>> > discussion of a "v2" protocol on the list which solves this, but it's
>> > sort of languishing in the design phase).
>>
>> As a potential 1.1 version, which could work in a backward-compatible
>> way with existing servers and no additional round-trip: what if, in the
>> smart HTTP protocol, the client advertised client capabilities with an
>> additional HTTP header (e.g.  "Git-Client-Caps: symrefs othershiny
>> featurenames"?  git-http-backend could then pass those capabilities to
>> git-upload-pack (--client-caps='...'), which could take them into
>> account in the initial response?
>>
>> That wouldn't work as a single-pass approach for SSH, since the client
>> can't know if the server's upload-pack supports --client-caps, but it
>> would work for the smart HTTP protocol.
>
> You can dig up the discussion on the list under the name "protocol v2",
> but basically yes, that approach has been considered. It's a little
> gross just because it leaves other protocols behind http (and it is not
> necessarily a good idea to push people into http, because it has some
> fundamental drawbacks over the other protocols because of its
> half-duplex nature).

Some more thoughts on protocol v2 (the good parts to be attributed to
jrnieder@gmail.com):

* In case of http we can use the http header and know information
  about the client, i.e. if it may support the following ideas:

* Instead of introducing a new protocol we introduce a capability\
  "resend-ref-advertisement" and only advertise very few refs (e.g.
  only the branches, not the pending changes in case of Gerrit)

* The client can then ignore the refs advertisement and ask for a resend
  of the refs with more specification,
  e.g. "want refs/heads/*", so allowing more than just sha1s in the
  want line but complex things like branch patterns.

>
>> > That should Just Work over the existing http protocol without requiring
>> > an extra request.
>>
>> It'd require one extra request for git ls-remote, which normally doesn't
>> need the second round-trip, but that still seems reasonable.
>
> Good point. I don't think there's an easy way around that short of v2 or
> v1.1 that you mention above. I agree it's probably reasonable, though.
>
> -Peff
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: upload-pack/ls-remote: showing non-HEAD symbolic refs?

[Josh Triplett]

On Tue, Aug 16, 2016 at 02:28:52PM -0400, Jeff King wrote:
> On Tue, Aug 16, 2016 at 10:34:44AM -0700, Josh Triplett wrote:
> 
> > > Sadly you cannot use a capability to fix that, because all of this
> > > happens before the client agrees to any capabilities (you can find
> > > discussion of a "v2" protocol on the list which solves this, but it's
> > > sort of languishing in the design phase).
> > 
> > As a potential 1.1 version, which could work in a backward-compatible
> > way with existing servers and no additional round-trip: what if, in the
> > smart HTTP protocol, the client advertised client capabilities with an
> > additional HTTP header (e.g.  "Git-Client-Caps: symrefs othershiny
> > featurenames"?  git-http-backend could then pass those capabilities to
> > git-upload-pack (--client-caps='...'), which could take them into
> > account in the initial response?
> > 
> > That wouldn't work as a single-pass approach for SSH, since the client
> > can't know if the server's upload-pack supports --client-caps, but it
> > would work for the smart HTTP protocol.
> 
> You can dig up the discussion on the list under the name "protocol v2",
> but basically yes, that approach has been considered. It's a little
> gross just because it leaves other protocols behind http (and it is not
> necessarily a good idea to push people into http, because it has some
> fundamental drawbacks over the other protocols because of its
> half-duplex nature).

I looked through the "protocol v2" threads, but couldn't find any
discussions of using HTTP headers.  I found some mentions of using
additional query parameters on the git-upload-pack request, which would
break compatibility with existing servers (they won't just ignore the
extra parameter).

--client-caps could work for SSH as well, it just requires an extra
round-trip to check for --client-caps.  Call git-upload-pack
--supports-client-caps, ignore any output (which with current git will
consist of a usage message), see if it returns a 0 exit code, if so,
call git-upload-pack --client-caps='...', and if not just call
git-upload-pack.  (A new git-upload-pack-2 binary would also work, but
that seems like overkill.)  I don't see any way around the extra round
trip here that would preserve backward compatibility with existing SSH
servers (which may force clients to *only* run exactly the command
"git-upload-pack" and nothing else).

Another possibility, which would work for both HTTPS and
git-protocol-over-TLS, would be to use ALPN.

git:// , however, would require a new service name, and that service
would have to accept client caps in-band.  That doesn't seem nearly as
important to support, though.  And that approach doesn't seem preferable
for HTTP, which would require modification to server configuration to
support the new path rather than an HTTP header to the existing path.

Re: upload-pack/ls-remote: showing non-HEAD symbolic refs?

[Josh Triplett]

On Tue, Aug 16, 2016 at 11:50:11AM -0700, Stefan Beller wrote:
> On Tue, Aug 16, 2016 at 11:28 AM, Jeff King <peff@peff.net> wrote:
> > On Tue, Aug 16, 2016 at 10:34:44AM -0700, Josh Triplett wrote:
> >
> >> > Sadly you cannot use a capability to fix that, because all of this
> >> > happens before the client agrees to any capabilities (you can find
> >> > discussion of a "v2" protocol on the list which solves this, but it's
> >> > sort of languishing in the design phase).
> >>
> >> As a potential 1.1 version, which could work in a backward-compatible
> >> way with existing servers and no additional round-trip: what if, in the
> >> smart HTTP protocol, the client advertised client capabilities with an
> >> additional HTTP header (e.g.  "Git-Client-Caps: symrefs othershiny
> >> featurenames"?  git-http-backend could then pass those capabilities to
> >> git-upload-pack (--client-caps='...'), which could take them into
> >> account in the initial response?
> >>
> >> That wouldn't work as a single-pass approach for SSH, since the client
> >> can't know if the server's upload-pack supports --client-caps, but it
> >> would work for the smart HTTP protocol.
> >
> > You can dig up the discussion on the list under the name "protocol v2",
> > but basically yes, that approach has been considered. It's a little
> > gross just because it leaves other protocols behind http (and it is not
> > necessarily a good idea to push people into http, because it has some
> > fundamental drawbacks over the other protocols because of its
> > half-duplex nature).
> 
> Some more thoughts on protocol v2 (the good parts to be attributed to
> jrnieder@gmail.com):
> 
> * In case of http we can use the http header and know information
>   about the client, i.e. if it may support the following ideas:
> 
> * Instead of introducing a new protocol we introduce a capability\
>   "resend-ref-advertisement" and only advertise very few refs (e.g.
>   only the branches, not the pending changes in case of Gerrit)
> 
> * The client can then ignore the refs advertisement and ask for a resend
>   of the refs with more specification,
>   e.g. "want refs/heads/*", so allowing more than just sha1s in the
>   want line but complex things like branch patterns.

That seems like something a client could advertise via client
capabilities.  For instance, if the client doesn't want the initial refs
list, only the server capabilities, it could say "capsonly".  (It might
also be reasonable to cache the knowledge that a server supports client
capabilities, though not any specific capability.)

Re: upload-pack/ls-remote: showing non-HEAD symbolic refs?

[Jeff King]

On Tue, Aug 16, 2016 at 01:31:50PM -0700, Josh Triplett wrote:

> > You can dig up the discussion on the list under the name "protocol v2",
> > but basically yes, that approach has been considered. It's a little
> > gross just because it leaves other protocols behind http (and it is not
> > necessarily a good idea to push people into http, because it has some
> > fundamental drawbacks over the other protocols because of its
> > half-duplex nature).
> 
> I looked through the "protocol v2" threads, but couldn't find any
> discussions of using HTTP headers.  I found some mentions of using
> additional query parameters on the git-upload-pack request, which would
> break compatibility with existing servers (they won't just ignore the
> extra parameter).

Probably the most interesting recent discussion is the sub-thread of
this patch:

  http://public-inbox.org/git/1460747949-3514-5-git-send-email-dturner@twopensource.com/

which you might have missed because it only messages "v2 protocol" in
the body.

But basically, I think you get the gist of it. We need to pass
information from the client to the server _before_ the initial
capability advertisement. For HTTP, we can do it via specialized headers
or query parameters. For other protocols, we're stuck with some kind of
try-and-fallback hack.

That means those protocols may diverge slightly from HTTP, but at least
they would differ only in the "bootstrap v2" bit (and that would
eventually become irrelevant as everybody moves to v2).

> --client-caps could work for SSH as well, it just requires an extra
> round-trip to check for --client-caps.  Call git-upload-pack
> --supports-client-caps, ignore any output (which with current git will
> consist of a usage message), see if it returns a 0 exit code, if so,
> call git-upload-pack --client-caps='...', and if not just call
> git-upload-pack.  (A new git-upload-pack-2 binary would also work, but
> that seems like overkill.)  I don't see any way around the extra round
> trip here that would preserve backward compatibility with existing SSH
> servers (which may force clients to *only* run exactly the command
> "git-upload-pack" and nothing else).

Yep, that's about it. For ssh, I suspect we could optimistically try:

  git upload-pack --v2; test $? = 129 && git-upload-pack

and then fallback to just "git-upload-pack". That would work without an
extra round-trip on real shell-capable servers, and eventually work on
restricted ones.

That doesn't help git://, though.

There are proposals floating around for basically easing into it with
config. Have a "remote.*.v2" option you can set locally to enable (or
disable) it. Default to "false". When there are enough v2 servers around
to make it worthwhile, flip the default to "auto" which will do the
probing (at some minor expense of handling fallbacks). Optionally we
could record the last response for "auto" and use that going forward.

> Another possibility, which would work for both HTTPS and
> git-protocol-over-TLS, would be to use ALPN.

Do people actually use git-over-TLS? There's no core support AFAIK, so
you'd have to hack it up with a client proxy and git-remote-ext.

For HTTPS, I'd just as soon use HTTP-level features.

-Peff

Re: upload-pack/ls-remote: showing non-HEAD symbolic refs?

[Josh Triplett]

On Tue, Aug 16, 2016 at 04:54:27PM -0400, Jeff King wrote:
> On Tue, Aug 16, 2016 at 01:31:50PM -0700, Josh Triplett wrote:
> 
> > > You can dig up the discussion on the list under the name "protocol v2",
> > > but basically yes, that approach has been considered. It's a little
> > > gross just because it leaves other protocols behind http (and it is not
> > > necessarily a good idea to push people into http, because it has some
> > > fundamental drawbacks over the other protocols because of its
> > > half-duplex nature).
> > 
> > I looked through the "protocol v2" threads, but couldn't find any
> > discussions of using HTTP headers.  I found some mentions of using
> > additional query parameters on the git-upload-pack request, which would
> > break compatibility with existing servers (they won't just ignore the
> > extra parameter).
> 
> Probably the most interesting recent discussion is the sub-thread of
> this patch:
> 
>   http://public-inbox.org/git/1460747949-3514-5-git-send-email-dturner@twopensource.com/
> 
> which you might have missed because it only messages "v2 protocol" in
> the body.

Thanks for the link.

> But basically, I think you get the gist of it. We need to pass
> information from the client to the server _before_ the initial
> capability advertisement. For HTTP, we can do it via specialized headers
> or query parameters. For other protocols, we're stuck with some kind of
> try-and-fallback hack.
> 
> That means those protocols may diverge slightly from HTTP, but at least
> they would differ only in the "bootstrap v2" bit (and that would
> eventually become irrelevant as everybody moves to v2).
> 
> > --client-caps could work for SSH as well, it just requires an extra
> > round-trip to check for --client-caps.  Call git-upload-pack
> > --supports-client-caps, ignore any output (which with current git will
> > consist of a usage message), see if it returns a 0 exit code, if so,
> > call git-upload-pack --client-caps='...', and if not just call
> > git-upload-pack.  (A new git-upload-pack-2 binary would also work, but
> > that seems like overkill.)  I don't see any way around the extra round
> > trip here that would preserve backward compatibility with existing SSH
> > servers (which may force clients to *only* run exactly the command
> > "git-upload-pack" and nothing else).
> 
> Yep, that's about it. For ssh, I suspect we could optimistically try:
> 
>   git upload-pack --v2; test $? = 129 && git-upload-pack
> 
> and then fallback to just "git-upload-pack". That would work without an
> extra round-trip on real shell-capable servers, and eventually work on
> restricted ones.

True, that seems completely sensible.

> That doesn't help git://, though.

I'd love to see plaintext git:// disappear through lack of use.

> There are proposals floating around for basically easing into it with
> config. Have a "remote.*.v2" option you can set locally to enable (or
> disable) it. Default to "false". When there are enough v2 servers around
> to make it worthwhile, flip the default to "auto" which will do the
> probing (at some minor expense of handling fallbacks). Optionally we
> could record the last response for "auto" and use that going forward.

That sounds sensible.

> > Another possibility, which would work for both HTTPS and
> > git-protocol-over-TLS, would be to use ALPN.
> 
> Do people actually use git-over-TLS? There's no core support AFAIK, so
> you'd have to hack it up with a client proxy and git-remote-ext.

I've seen the idea bounced around and prototyped in the context of
supporting authenticated push to git://

> For HTTPS, I'd just as soon use HTTP-level features.

ALPN, used carefully, could potentially allow eliminating one round-trip
compared to HTTPS, and could also allow full-duplex communication.

- Josh Triplett

Re: upload-pack/ls-remote: showing non-HEAD symbolic refs?

[Jeff King]

On Tue, Aug 16, 2016 at 02:11:41PM -0700, Josh Triplett wrote:

> > For HTTPS, I'd just as soon use HTTP-level features.
> 
> ALPN, used carefully, could potentially allow eliminating one round-trip
> compared to HTTPS, and could also allow full-duplex communication.

I'd love to have a real full-duplex git-over-https. I looked into
WebSockets at one point, but it looked non-trivial and I gave up.

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).

-Peff

Re: upload-pack/ls-remote: showing non-HEAD symbolic refs?

[Josh Triplett]

On Tue, Aug 16, 2016 at 05:15:51PM -0400, Jeff King wrote:
> On Tue, Aug 16, 2016 at 02:11:41PM -0700, Josh Triplett wrote:
> 
> > > For HTTPS, I'd just as soon use HTTP-level features.
> > 
> > ALPN, used carefully, could potentially allow eliminating one round-trip
> > compared to HTTPS, and could also allow full-duplex communication.
> 
> I'd love to have a real full-duplex git-over-https. I looked into
> WebSockets at one point, but it looked non-trivial and I gave up.

WebSockets would be non-trivial, and require server configuration as
well, but it could work.

> 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.

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.

- Josh Triplett

Re: upload-pack/ls-remote: showing non-HEAD symbolic refs?

[Jeff King]

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