Hello Sébastien, On Fri, Jul 08, 2011 at 11:17:12PM +0200, Sébastien Estienne wrote: > yes we perfectly understand this, and that is what we like about haproxy. > But the demand for SSL is growing, it s even mandatory for some use cases. > Stud looks really promising and solid and a good match for haproxy as it was > designed to be used with haproxy ( http://devblog.bu.mp/introducing-stud ). > Today we have the choice between: > - haproxy 1.4 + patched stunnel > - haproxy 1.5 dev + stud > - patched haproxy 1.4 + stud > > The last one seems the most stable with the best performance, so as the > demand for SSL is growing, i think it would be a big plus that haproxy 1.4 > can work with stud without being patched.
I see your point. Well, there is also a fourth solution. At Exceliance, we have an "haproxy enterprise edition (hapee)" packaging which includes a patched haproxy 1.4, patched stunnel etc... There's a free version you can register for. We decided to install it as some of our supported customers for free, just because it made maintenance easier for us, and rendered their infrastructure more stable. > I don t know if it would make sense but maybe stud could be integrated > somehow in haproxy like this: > Instead of starting stud then haproxy separately, the main haproxy process > could fork some stud-like process (binding 443) as it already forks haproxy > childs for multicore and it would discuss using the proxy protocol > transparentlyfor the end user with no need to setup the link between both. It's amusing that you're saying that : when I looked at the code, I thought "they use the same design model as haproxy and they have the same goals, maybe this could be merged". My goal with SSL in haproxy is that we can dedicate threads or processes to that task, thus some core changes are still needed, but a first step might precisely be to have totally independant processes communicating over a unix socket pair and the proxy protocol. It's just not trivial yet to reach the server in SSL, but one thing at a time... > This would offer a seemless SSL integration without hurting haproxy codebase > and stability for clear http content. Exactly. Thanks for your insights, they comfort me in that mine were not too excentric :-) Willy
