Hi Cyril, On Fri, Nov 12, 2010 at 02:07:22PM +0100, Cyril Bonté wrote: > > - support for binding to UNIX socket on the accept side. Haproxy can > > now receive connections over a UNIX socket. This is particularly > > useful when combined with stunnel (we also have a patch for that > > in the 'patches' directory). > > First of all, it works :-) But using ab to stress stunnel+haproxy, I got some > "SSL read failed" errors (with at least 10 concurrent connections on a > laptop). I suspect it comes from ab and not from stunnel or haproxy, but as > soon as I go back to TCP instead of a UNIX socket, I don't have these errors. > I also tested stunnel+nginx with UNIX sockets, still no error. > And replacing ab with httperf, it always works.
Do you know if keep-alive was involved in any of these tests ? > > - support for a new "PROXY" protocol that was designed to forward > > transport-level information between proxies. The idea is to permit a > > component like stunnel to inform haproxy about the protocol, source > > and destinations of an incoming connection, so that haproxy can make > > use of that everywhere internally (acls, logs, transparent, ...) > > instead of stunnel's address. The main advantage over the > > x-forwarded-for patch is that it now supports keep-alive and is not > > limited to HTTP anymore. When combined with the UNIX socket, it can make > > haproxy and stunnel integrate seamlessly and reliably. Obviously, we have > > a patch for stunnel ready too ;-) > > It didn't work with "option http-server-close". My guess is that the > AN_REQ_DECODE_PROXY bit is re-enabled after the first transaction. > I don't provide a full patch because I don't know if it's the better > solution, > but applying this fixes the issue : > --- haproxy-1.5-dev3/src/proto_http.c 2010-11-11 23:29:35.000000000 +0100 > +++ /home/cbonte/Public/haproxy/haproxy-1.5-dev3/src/proto_http.c > 2010-11-12 > 13:53:14.154398641 +0100 > @@ -3949,6 +3949,7 @@ > s->rep->lr -= s->req->size; > > s->req->analysers |= s->listener->analysers; > + s->req->analysers &= ~AN_REQ_DECODE_PROXY; > s->rep->analysers = 0; > > http_silent_debug(__LINE__, s); > Good catch, you're perfectly right, I did not think about this case ! Right now we should apply your fix as-is. Later we'd probably try to split analysers between connection-based and transaction-based. > I'll make some tests on the other features soon. Thanks ! Willy
