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

["H. Peter Anvin" <hpa@zytor.com>]

Shawn O. Pearce wrote:
> 
>> 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