Re: More on git over HTTP POST

From: Shawn O. Pearce <spearce@spearce.org>
Date: Aug 3, 2008, 02:56 UTC
Message-ID: <20080803025602.GB27465@spearce.org>
In-Reply-To: <20080802205702.GA24723@spearce.org>

"Shawn O. Pearce" <spearce@spearce.org> wrote:

Show 7 quoted lines

> "H. Peter Anvin" <hpa@zytor.com> wrote:
> > I have investigated a bit what it would take to support git protocol  
> > (smart transport) over HTTP POST transactions.
> 
> I have started to think about this more myself, not just for POST
> put also for some form of GET that can return an efficient pack,
> rather than making the client walk the object chains itself.

...

> HTTP POST is actually trivial if you don't want to support the new
> tell-me-more extension that was added to git-push.  Hell, I could
> write the CGI in a few minutes I think.  Its really just a small
> wrapper around git-receive-pack.

So I have this draft of how smart push might work. Its slated for the Documentation/technical directory. Thus far I have only written about push support, but Ilari on #git has some ideas about how to do a smart fetch protocol.

Implementation wise in C git I think this is just a new C program (git-http-backend?) that turns around and proxies into git-receive-pack, at least for the push support.

What I don't know is how we could configure URI translation from /path/to/repository.git received out of the $PATH_INFO in the CGI environment to a physical directory. Should we rely on the server's $PATH_TRANSLATED?

Smart HTTP transfer protocols =============================

Git supports two HTTP based transfer protocols. A "dumb" protocol which requires only a standard HTTP server on the server end of the connection, and a "smart" protocol which requires a Git aware CGI (or server module). This document describes the "smart" protocol.

Authentication --------------

Standard HTTP authentication is used, and must be configured and enforced by the HTTP server software.

Chunked Transfer Encoding -------------------------

For performance reasons the HTTP/1.1 chunked transfer encoding is used frequently to transfer variable length objects. This avoids needing to produce large results in memory to compute the proper content-length.

Detecting Smart Servers -----------------------

HTTP clients can detect a smart Git-aware server by sending the show-ref request (below) to the server. If the response has a status of 200 and the magic x-application/git-refs content type then the server can be assumed to be a smart Git-aware server.

If any other response is received the client must assume dumb protocol support, as the server did not correctly response to the request.

Show Refs ---------

Obtains the available refs from the remote repository. The response is a sequence of git "packet lines", one per ref, and a final flush packet line to indicate the end of stream.

	C: GET /path/to/repository.git?show-ref HTTP/1.0

	S: HTTP/1.1 200 OK
	S: Content-Type: x-application/git-refs
	S: Transfer-Encoding: chunked
	S:
	S: 62
	S: 003e95dcfa3633004da0049d3d0fa03f80589cbcaf31 refs/heads/maint
	S: 
	S: 63
	S: 003fd049f6c27a2244e12041955e262a404c7faba355 refs/heads/master
	S: 
	S: 59
	S: 003b2cb58b79488a98d2721cea644875a8dd0026b115 refs/heads/pu
	S: 
	S: 4
	S: 0000
	S: 0

Push Pack ---------

Uploads a pack and updates refs. The start of the stream is the commands to update the refs and the remainder of the stream is the pack file itself. See git-receive-pack and its network protocol in pack-protocol.txt, as this is essentially the same.

	C: POST /path/to/repository.git?receive-pack HTTP/1.0
	C: Content-Type: x-application/git-receive-pack
	C: Transfer-Encoding: chunked
	C:
	C: 103
	C: 006395dcfa3633004da0049d3d0fa03f80589cbcaf31 d049f6c27a2244e12041955e262a404c7faba355 refs/heads/maint
	C: 4
	C: 0000
	C: 12
	C: PACK
	...
	C: 0

	S: HTTP/1.0 200 OK
	S: Content-type: x-application/git-status
	S: Transfer-Encoding: chunked
	S:
	S: ...<output of receive-pack>...

-- 
Shawn.