Re: redirections using http 302 / other way?

From: Willy Tarreau <w#1wt.eu>
Date: Mon, 21 Jan 2008 22:25:55 +0100


Hello Florian,

On Mon, Jan 21, 2008 at 08:39:53AM +0100, florian iragne wrote:
> Hello everybody,
>
> I'm trying to move from pound to haproxy and currently, there is one
> last thing that i can't move. I'm using Pound to redirect clients to
> serveral servers using http 302 code (load balancing is done with round
> robin), so that the chosen server directly replies to the client,
> avoiding the response through the server hosting Pound. This is
> necessary to maximize the bandwidth.

Well, do you need *that* much bandwidth ? My first tests with a 10 GigE NIC in a poor machine showed around 3 Gbps of throughput. I could certainly understand the reason for not wanting to put a lot of stress on a single machine though.

> With Haproxy, i see that 302errorloc is available, but not for this
> purpose. So my question is : is there a way, in Haproxy, to do the same
> (or similar) redirection than the one i currently make with Pound?

Not yet. I've already noted this in my (low priority) todo list because one user once asked me about multi-site load balancing with small uplinks. I figured out that this method combined with cookie-based persistence could very well fit those needs.

However you must keep in mind that it is dangerous. For instance, a POST request redirected using a 302 would result in a POST to the new URI, with without the data. If a user is about to upload an attachment in a webmail just before the server or access collapses and a 302 is returned to another server, depending on the application, the user may post an empty attachment without being aware of it, for instance.

Anyway, I don't think it's too hard to implement. We should add another server option indicating that this server should result in a 302 (or 303) with the URI returned in the Location: field. All basic checking methods would still be there. I think that this is not much complicated.

Regards,
Willy Received on 2008/01/21 22:25

This archive was generated by hypermail 2.2.0 : 2008/01/21 23:00 CET