Re: [PATCH] Add persistent-https to contrib

Colby Ranger [off-list ref] writes:

Git over HTTPS has a high request startup latency, since the SSL
negotiation can take up to a second. In order to reduce this latency,
connections should be left open to the Git server across requests
(or invocations of the git commandline).

Reduce SSL startup latency by running a daemon job that keeps
connections open to a Git server. The daemon job
(git-remote-persistent-https--proxy) is started on the first request
through the client binary (git-remote-persistent-https) and remains
running for 24 hours after the last request, or until a new daemon
binary is placed in the PATH. The client determines the daemon's
HTTP address by communicating over a UNIX socket with the daemon.

quoted

From there, the rest of the Git protocol work is delegated to the

"git-remote-http" binary, with the environment's http_proxy set to
the daemon.

Signed-off-by: Colby Ranger <redacted>

Clever.  Do you have some numbers?

If this persistent proxy weren't in the picture, the git client would
directly delegate its communication with the origin server to
git-remote-https, and git-remote-https would interact with the credential
API to handle authentication for "https://origin.server.xz/repo".

How does the persistent proxy sitting in between your git client and the
origin server and/or the real proxy you have at the perimeter of your
network interact with respect to authentication/authorization to access
the repository or the real proxy?  They will talk with the persistent
proxy, and the persistent proxy will talk with the git client via
git-remote-http, and I am assuming that this last git-remote-http will be
the one that uses the credential API.  Would it ask credential for
"https://origin.server.xz/repo"?  "http://origin.server.xz/repo"?  Or
would it be "persistent-https://origin.server.xz.repo"?

 contrib/persistent-https/COPYING    |  202 +++++++++++++++++++++++++++++++++++

I do not mind carrying this in the contrib/ area (I am assuming that
distributing Apache licensed software that does not link with GPLv2 core
is OK).  It may be just me, but a file called COPYING that does not have
GPL text in it was a bit surprising.  I wonder if it is more customary to
call it either LICENSE (or perhaps LICENSE-2.0)?

 contrib/persistent-https/README     |   62 +++++++++++
 contrib/persistent-https/client.go  |  178 ++++++++++++++++++++++++++++++
 contrib/persistent-https/main.go    |   82 ++++++++++++++
 contrib/persistent-https/proxy.go   |  190 ++++++++++++++++++++++++++++++++
 contrib/persistent-https/release.sh |   45 ++++++++
 contrib/persistent-https/socket.go  |   97 +++++++++++++++++
 contrib/persistent-https/tar.sh     |   40 +++++++
 8 files changed, 896 insertions(+)

It might deserve its own contrib/persistent-https/Makefile in addition to
your internal "release" scripts, though.