Re: Git-aware HTTP transport

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

Shawn O. Pearce wrote:
> 
> Hmm.  I'm actually thinking the exact opposite here.  My rationale
> for putting the response as a standard HTTP 302/303 style redirect
> is to permit hardware load balancers or Apache mod_rewrite rules
> to implement simple load balancing with a HTTP redirect.
> 
> If we embed the redirect URL into the payload then configuring that
> will become a lot more complex.  At the minimum you may have to
> make up a dummy file for each server (holding the response payload)
> then then let mod_rewrite rewrite the request internally to make
> Apache serve that file.  Ugly.
> 

No, you're thinking backwards.  What you want is the standard HTTP 
redirect load balancing to take effect *before* the initial request is 
serviced.  The front-end load balancer will take effect on the initial 
request, and then redirect the request to a node (via a 302 reply.)  The 
target node then sends a self-referencing URL to keep the service local, 
if that is desired -- otherwise it doesn't.

Again, the 300-class redirect is treated as a part of the HTTP transport 
in this case; it doesn't have to be visible to the RPC layer.  However, 
in order to maintain the integrity of an interchange, we do need an 
additional level of redirection visible to the RPC layer.

> If we embed the redirect URL into the payload then configuring that
> will become a lot more complex.  At the minimum you may have to
> make up a dummy file for each server (holding the response payload)
> then then let mod_rewrite rewrite the request internally to make
> Apache serve that file.  Ugly.

A very simple CGI/PHP script will do this, and it's really very very 
trivial to set up.

Please keep in mind I'm not talking hypotheticals at all.  What you have 
proposed is actually a lot uglier for kernel.org to implement, simply 
because we try to stay with strict IP-based vhosting

	-hpa