Ah, sorry, I was using the one in Debian (experimental) from 2013-12-17. When I upgraded to 2014-01-18 (1.5~dev21+20140118-1) then the problem did not persist!
Thanks for the information! Regards, Oskar -----Original Message----- From: Baptiste [mailto:[email protected]] Sent: Thursday, January 23, 2014 12:27 To: Oskar Liljeblad Cc: [email protected] Subject: Re: tune.bufsize issue with send-proxy / accept-proxy SSL setup Hi Oskar, Are you using the latest git version? If no, please give it a try, there may be a fix which apply to this case. Baptiste On Thu, Jan 23, 2014 at 12:22 PM, Oskar Liljeblad <[email protected]> wrote: > Hello > > > > Our HAProxy 1.5~dev21 setup looks like this: > > > > client browser -> haproxy1 -> haproxy2 -> web servers > > > > - client browser sends as https. > > - haproxy1 receives with mode tcp frontend, and sends using mode tcp backend > with send-proxy. > > - haproxy2 receives with mode http frontend with ssl accept-proxy, and sends > using mode http backend to web servers. > > > > The problem: when clients send a POST requests with >8K payload, the request > will appear to hang in the client, and eventually be aborted after 30 > seconds. (Our "timeout client" and "timeout server" settings are 30s.) So > the client receives no response and I believe HAProxy closes the connection. > > > > A workaround/fix for this problem is to set "tune.bufsize 24576" on the > second haproxy above (haproxy2). (I assume lowering tune.maxrewrite instead > may work as well.) > > However, the documentation recommends against changing tune.bufsize. And we > really don't want to limit POST payload size. Is this expected behavior? > Especially considering that it happens to POST requests and not only GET > requests in our setup. > > > > Regards, > > > > Oskar Liljeblad > >
