Thanks Willy and Nenand!
On Fri, Jul 22, 2016 at 5:44 AM, Willy Tarreau <[email protected]> wrote: > 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 > >
