Re: [RFC 2/2] Add Git-aware CGI for Git-aware smart HTTP transport

From: Shawn O. Pearce <spearce@spearce.org>
Date: Aug 5, 2008, 01:57 UTC
Message-ID: <20080805015717.GB383@spearce.org>
In-Reply-To: <4897AE53.4030107@zytor.com>

"H. Peter Anvin" <hpa@zytor.com> wrote:

Show 9 quoted lines

> Shawn O. Pearce wrote:
>>
>> I think it is a really good idea.  Then clients don't have to worry
>> about which HTTP URL is the "correct" one for them to be using.
>
> Not arguing that URL compatibility isn't a good thing, but there are  
> other ways to accomplish it, too.  After detecting either a smart or  
> dumb server, we can use a redirect to point them to a different URL, as  
> appropriate.

I'm not sure this is necessary.

Of course it all comes down to "how does an admin map Git repositories into the URL space of the server"?

I thought it would be simple if the admin was able to map repositories using a ScriptAlias and allow the server to perform path info translation to give us the filesystem location of the repository. Then we don't have to configure our own map of the available Git repositories.

Once you do that though you now have the URL space associated with that repository served by a CGI. For older clients we need to either serve them the file, or issue a redirect to serve the file. The redirect is messy because we need some configuration to explain where the files are available in the server's URL space.

Or you go the other way, and have newer git+http clients try to find the git aware server by a redirect. Again we have to explain where that git aware server is in the URL space of the server.

*sigh*

> Furthermore, in the case of round-robin sites like kernel.org, this is  
> actually *mandatory* in the case of a stateful server (we need a  
> redirect to a server-specific URL), and highly recommended in the case  
> of a stateless server (because of potential skew.)

Well, the git+http protocol will hold all state in the client, making each RPC a stateless RPC operation. The only issue is then dealing with skew in a server farm.

I guess we need to ask client implementations to honor a redirect on the first request and reuse that new base URL for all subsequent requests that are part of the same "operation". Then server farms can issue a redirect to a server-specific hostname if a client comes in with a round-robin DNS hostname, thus ensuring that for this current operation there isn't skew.

-- 
Shawn.