I'm using haproxy 1.4.17 if that's relevant. I tried replacing http-server-close with http-pretend-keepalive, which as far as I can tell had no effect to client side keepalive behaviour. Responses still looked something like this:
< HTTP/1.1 200 OK < Server: Apache-Coyote/1.1 < Cache-Control: max-age=125 < Content-Type: application/json;charset=UTF-8 < Date: Thu, 31 Jan 2013 13:25:54 GMT < Connection: close < * Closing connection #0 I then tried enabling keepalive on the backend (tomcat), after which curls directly too the backend looked like: < HTTP/1.1 200 OK < Server: Apache-Coyote/1.1 < Cache-Control: max-age=63 < Content-Type: application/json;charset=UTF-8 < Transfer-Encoding: chunked < Date: Thu, 31 Jan 2013 13:24:13 GMT < * Connection #0 to host HOST left intact But responses from haproxy still closed with either http-server-close or http-pretend-keepalive set still close the connection. I admit these results are confusing and I feel like I'm missing something. On 01/31/2013 02:28 AM, Willy Tarreau wrote: > On Wed, Jan 30, 2013 at 05:16:26PM -0800, Bryan Talbot wrote: >> http-pretend-keepalive still enables keep-alive to the client like >> http-server-close does. >> >> The difference is that http-server-close sends a Connection: close to the >> backend to indicate it doesn't intend to use keep alive. This however >> confuses some tomcat versions and causes them to act like the request was >> using HTTP 1.0 and (i think) send a connection: close in the response which >> is what your client is seeing. http-pretend-keepalive makes haproxy not >> send that Connection: close to the backend but then it closes the >> connection anyway. > > It's not just a matter of Connection header or HTTP version, the real issue > is that the server fails to announce the content-length nor chunked encoding, > making it impossible to maintain the connection alive with the client because > there is no other way to end the response than by closing. And you're > perfectly > right, using http-pretend-keepalive forces tomcat to emit these precious > headers to delimit the response, allowing the front connection to remain > alive. > > Willy >
