Colby Ranger <cranger@xxxxxxxxxx> 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. >>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 <cranger@xxxxxxxxxx> 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. -- 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