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

From: H. Peter Anvin <hpa@zytor.com>
Date: Aug 5, 2008, 01:35 UTC
Message-ID: <4897AE53.4030107@zytor.com>
In-Reply-To: <20080805012459.GC32543@spearce.org>

Shawn O. Pearce wrote:

Show 24 quoted lines

> 
>> I'm not sure if "emulating a dumb server" is desirable at all; it seems  
>> like it would at least in part defeat the purpose of minimizing the  
>> transaction count and otherwise be as much of a "smart" server as the  
>> medium permits.
> 
> 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.
> End users will just magically get the smart git+http variant if
> both sides support it and they need to use HTTP due to firewalls.
> Clients will fall back onto the dumb protocol if the server doesn't
> support smart clones.  Older clients (pre git+http) will still be
> able to talk to a smart server, just slower.  This is nice for the
> end user.  No thinking is required.
> 
> Never ask a human to do what a machine can do in less time.
> 
> I think its just 1 extra HTTP hit per fetch/push done against
> a dumb server.  On a smart server that first hit will also give
> us what we need to begin the conversation (the info/refs data).
> On a dumb server its a wasted hit, but a dumb server is already
> doing to suck.  One extra HTTP request against a dumb server is a
> drop in the bucket.  Its also a pretty small request (an empty POST).
>

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.

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.)

	-hpa