Add Git-aware CGI for Git-aware smart HTTP transport

Add Git-aware CGI for Git-aware smart HTTP transport

[H. Peter Anvin]

Anything we can do to keep this moving forward?  I was extremely 
encouraged with the fast progress on this; this would be great to get to 
the point where we (kernel.org) can deploy it at least for testing.

	-hpa

Re: Add Git-aware CGI for Git-aware smart HTTP transport

[Shawn O. Pearce]

"H. Peter Anvin" <hpa@zytor.com> wrote:
> Anything we can do to keep this moving forward?  I was extremely  
> encouraged with the fast progress on this; this would be great to get to  
> the point where we (kernel.org) can deploy it at least for testing.

Sorry, I dropped it with my egit work.  I'll pick it up again and
try to continue it further.  I left off trying to implement the
push client and saying "damn, jgit is better structured to make this
sort of change than C git" and decided it was too late at night to
continue it more.  That was like a week ago.

-- 
Shawn.

Re: Add Git-aware CGI for Git-aware smart HTTP transport

[Shawn O. Pearce]

[...added git ML back to thread...]

"H. Peter Anvin" <hpa@zytor.com> wrote:
> Shawn O. Pearce wrote:
>> The plan I've proposed requires wedging the CGI in between the HTTP
>> server and the repository files.  Which means older dumb clients
>> get data by forking off the CGI, rather than letting the HTTP server
>> stream the file itself.
>
> Yeah, that's quite a bit unfortunate, because it means some potentially  
> very expensive buffering in Apache.  That's one reason to do some kind  
> of redirection.

Hmm.  So what if the "smart" protocol used a redirect to the CGI
and the dumb protocol didn't use any redirects at all?  I say this
because I think the dumb protocol won't handle redirects well.
It will do them, but it would incur a redirect on every request
it makes.

So if we have the "smart" protocol perform detection by trying:

	C: HEAD /path/to/repository.git/git-http-backend HTTP/1.0

	S: HTTP/1.0 302 Found
	S: Location: /git-http/path/to/repository.git

Under Apache this server configuration can be easily handled by a
mod_rewrite regex:

	RewriteRule ^(/pub/scm/.*)/git-http-backend$ /git/$1 [R,L]
	ScriptAlias /git/ /path/to/git-http-backend/

Individual users could also install the git-http-backend CGI
right into their repository, in which case the CGI if invoked with
no PATH_INFO can do a redirect back to itself to indicate where
GIT_DIR is:

	C: HEAD /path/to/repository.git/git-http-backend HTTP/1.0

	S: HTTP/1.0 302 Found
	S: Location: /path/to/repository.git/git-http-backend/.

Individual operations can be selected by appending on the operation
name, so <Location ~ > style rules can be used to apply access
controls, such as:

	# Disallow push to any smart repository via ScriptAlias
	#
	<Location ~ ^/git/.*/receive-pack$>
		Order Deny,Allow
		Deny from all
	</Location>

	# Disallow push to any smart repository with CGI in tree.
	#
	<Location ~ .*/git-http-backend/./receive-pack$>
		Order Deny,Allow
		Deny from all
	</Location>

Setting this up on a server which doesn't have the power of mod_regex
available would be tricky, as you need to link the CGI into every
single repository you are serving.  I don't know (or use) many other
HTTP servers beyond Apache so I'm not sure if they can do this.

-- 
Shawn.

Re: Add Git-aware CGI for Git-aware smart HTTP transport

[H. Peter Anvin]

Shawn O. Pearce wrote:
> 
> Hmm.  So what if the "smart" protocol used a redirect to the CGI
> and the dumb protocol didn't use any redirects at all?  I say this
> because I think the dumb protocol won't handle redirects well.
> It will do them, but it would incur a redirect on every request
> it makes.
> 

That's preferrable anyway, in my opinion.

> Setting this up on a server which doesn't have the power of mod_regex
> available would be tricky, as you need to link the CGI into every
> single repository you are serving.  I don't know (or use) many other
> HTTP servers beyond Apache so I'm not sure if they can do this.

Many can, and even more can if we instead of git-http-backend had 
something which looked vaguely like a unique extension, like 
"backend.git-http"

	-hpa