On Feb 27, 2015, at 17:01, Stefan Beller wrote:
From: Nguyễn Thái Ngọc Duy <pclouds@xxxxxxxxx>
The only difference from the original protocol client capabilities are
negotiated before initial refs advertisment.
Client capabilities are sent out of band (upload-pack receives it as
the second command line argument). The server sends one pkt-line back
advertising its capabilities.
Signed-off-by: Stefan Beller <sbeller@xxxxxxxxxx>
---
Notes:
v1:
I am still undecided if the client should then accept/resend
the capabilities to confirm them, which would make the client the
ultimate decider which capabilities are used.
My gut feeling is to rather let the server make the final decision
for the capabilities, as it will use some requested capabilities
already to not send out all the refs.
Documentation/git-upload-pack.txt | 10 +++++++++-
upload-pack.c | 42 ++++++++++++++++++++++++++
+------------
2 files changed, 38 insertions(+), 14 deletions(-)
diff --git a/Documentation/git-upload-pack.txt b/Documentation/git-
upload-pack.txt
index 0abc806..ad3a89d 100644
--- a/Documentation/git-upload-pack.txt
+++ b/Documentation/git-upload-pack.txt
@@ -9,7 +9,7 @@ git-upload-pack - Send objects packed back to git-
fetch-pack
SYNOPSIS
--------
[verse]
-'git-upload-pack' [--strict] [--timeout=<n>] <directory>
+'git-upload-pack' [--strict] [--timeout=<n>] <directory>
[<capabilities>]
Isn't the problem with this that passing the extra argument to ssh
servers will cause them to fail?
Having just looked at the upload-pack.c source it looks to me like
trying to send "git-upload-pack 'dir' 'capabilities'" to an ssh git
server running a current version of the code will just end up
failing. I realize the extra argument is optional, so does that mean
there's no out-of-band support for ssh connections since the extra
argument would have to be omitted to remain compatible?
On Feb 26, 2015, at 12:13, Junio C Hamano wrote:
The capability-based sidegrade does not solve the problem
when the problem to be solved is that the server side needs to spend
a lot of cycles and the network needs to carry megabytes of data
before capability exchange happens.
On Feb 27, 2015, at 16:46, Stefan Beller wrote:
I'll try to present a 'client asks for options first out of band'
instead of the
way you describe.
On Feb 27, 2015, at 15:44, Stefan Beller wrote:
For both native git as well as ssh, Duy presented a solution at [1, 2]
a year ago, which essentially presents the desired client capabilites
'out of band' to the server via an argument to the server. So we'd
only need to examine the http(s) path how to pass in arguments there.
I've looked at those links and it's unclear to me how they support an
out-of-band option for ssh, they seem to be targeted at git-daemon.
Maybe there's another reference?
But there does seem to be a way to pass the protocol information out-
of-band for each of the HTTP, git and ssh connections to stop the
initial ref advertisement.
As already suggested [1, 2], for git: another "Extended attribute" can
be added after the host=...\0 to become host=...\0protocol=extended\0
or similar:
For HTTP, just add a second parameter in the query string .../info/
refs?service=git-upload-pack&protocol=extended. Alternatively an "X-
Git-Protocol: extended" or similar header can be added by the client.
It looks to me like the current http-backend.c already ignores any
extra parameters/headers.
That leaves ssh. A bit more problematic, but if the server side adds
"AcceptEnv GIT_PROTOCOL" to its sshd_config and then the client does
setenv("GIT_PROTOCOL","extended") and adds a "-o SendEnv=GIT_PROTOCOL"
option to the ssh command line the GIT_PROTOCOL variable will be
passed along. This one might need a config option to always disable
adding the "-o ..." option to the command line in case connect.c
guesses wrongly about it being OpenSSH and such is not likely to be
supported other than with OpenSSH on both ends. I'm not seeing any
other way to pass out-of-band information to an ssh server configured
to run git-shell that is safely ignored by current versions of the code.
Worst case with SSH is the initial ref advertisement is not suppressed
even though the server does support protocol v2 and a capability-based
sidegrade is required which is unfortunate.
-Kyle
[1] https://github.com/pclouds/git/commit/e26fa77c4d9ace06b9f2c80091af9eb7b63a1c95
[2] https://github.com/pclouds/git/commit/20d048e5fc650b20fdc7dd8bbe35cb8510ac9c50
--
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