Re: Git-aware HTTP transport

From: H. Peter Anvin <hpa@zytor.com>
Date: Aug 26, 2008, 16:33 UTC
Message-ID: <48B4303C.3080409@zytor.com>
In-Reply-To: <20080826145857.GF26523@spearce.org>

Shawn O. Pearce wrote:

Show 12 quoted lines

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

Show 5 quoted lines

> 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