Hi Pavlos, On Fri, Jul 22, 2016 at 12:33:07AM +0200, Pavlos Parissis wrote: > On 21/07/2016 10:30 ????, Willy Tarreau wrote: > > Hi, > > > > On Thu, Jul 21, 2016 at 02:33:05PM -0400, CJ Ess wrote: > >> I think I'm overlooking something simple, could someone spot check me? > >> > >> What I want to do is to pool connections on my http backend - keep HAProxy > >> from opening a new connection to the same backend if there is an > >> established connection that is idle. > >> > >> My haproxy version is 1.5.18 > > (...) > > > >> There is more then enough traffic going through the backend that if a > >> connection is idle, there will be a request that could use it (within ms, > >> should never hit the 5s or 75s timeouts), however in every case the > >> connection just sites idle for five seconds then closes. > >> > >> Am I missing something simple to enable this behavior? > > > > Yes, you're missing the "http-reuse" directive which was introduced in > > 1.6. Be careful when doing this (read the doc carefully), as some > > servers still tend to confuse requests and connections and could do > > some funny stuff there. > > Can you elaborate a bit more on this? > Which servers? Nginx/Apache and under which conditions ?
Some application servers (or some components) tend to tie some incoming parameters to the connection instead of the request. There used to be a lot of confusion regarding this when keep-alive was brought to HTTP because it was the era where reverse proxies would not even exist so there was no doubt that a connection always comes from a client. Unfortunately some bad designs were introduced due to this. The most widely known certainly is NTLM, which violates HTTP since it assumes that all requests coming over a connection belong to the same client. HAProxy detects this by marking a connection "private" as soon as it sees a 401 or 407 on it, and will not share it with any other client. But regardless of this, you'll find dirty applications which assign a cookie only after the 2nd or 3rd request over a given connection. Some will only emit a response cookie on the first response so the next requests will never get a cookie. Other ones will only check the X-Forwarded-For header when the connection establishes and will use this value for all requests from the connection, resulting in wrong logs and/or possibly rules. Others will simply take a decision on the first request of a connection and not check the remaining ones (like haproxy used to do up to version 1.3 and can still do when forced in tunnel mode). Most often the application components which break these HTTP principles are the ones which do not support a load balancer. But sometimes some of them work when you install a load balancer working in tunnel mode in front of them (like haproxy up to 1.3 by default). A rule of thumb is that if your application only works when you have "option prefer-last-server", then your application certainly is at risk. This problem has been widely discussed inside the IETF HTTP working group and is known as "requests must work in isolation". It's been quite well documented over the years and normally all modern components are safe. But if you connect to a good old dirty thing developed in the early 2000, be careful! Similarly, when using 3rd party apache modules developed by people doing a quick and dirty thing, be prepared to discover the hard way that they never read an RFC in their life... Cheers, Willy
