I am forced to use http-server-close because in our application we need to know the remote IP addresses of the users which are connecting to our service. And for this we need to use "option forwardfor". And the problem when using forwardfor and keepalive is that only some of the requests include the "X-Forwarded-For" header. Then we are using http-server-close to use only keep alive in the connections from browser to haproxy and not in the connections from haproxy to the backend servers. This way we force all the requests to include the X-Forwarded-For header.
But then we found the problem that I explained in my first email which, summing up, is that http-server-close breaks keepalive support in the browser-haproxy connections when using some backend servers (Tomcat and Jetty at least). Oscar On Tue, Mar 30, 2010 at 20:29, Nicolas Maupu <nma...@gmail.com> wrote: > From documentation, it seems to be an option to provide keep-alive from > backend which cannot support it ... > Keep-Alive connection is only on frontend side, not from backend ! > > So for chunked problem, it is easy to understand : > RFC 2616 (http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html) says : > > - Whenever a transfer-coding is applied to a message-body, the set of > transfer-codings MUST include "chunked", unless the message is terminated > by > closing the connection > - The chunked encoding modifies the body of a message in order to > transfer it as a series of chunks > > So chunk transfers need a keep-alive connection. If a connection: close > header is present, server should not proceed with chunk transfer ... > > Why do you want to use http-server-close option ? > Why not to use directly Keep-Alive ability of tomcat Connector and specify > 'no option httpclose' in haproxy ? This way, haproxy should act > transparently using keep-alive ability of tomcat connector. > > nm. > > > > On Tue, Mar 30, 2010 at 20:07, Nicolas Maupu <nma...@gmail.com> wrote: > >> Hi, >> >> I just wanted to confirm that HAproxy replaces Connection: Keep-Alive with >> Connection: close. >> I configured haproxy with a listen section with a backend server on port >> 80 and put option http-connection-close >> I opened a port with netcat on the backend machine : >> sudo nc -l -p 80 >> >> And finally, I tried to telnet to haproxy et get a page : >> telnet 192.168.10.148 80 >> Trying 192.168.10.148... >> Connected to 192.168.10.148. >> Escape character is '^]'. >> GET / HTTP/1.1 >> Host: toto >> Connection: Keep-Alive >> >> Netcat received in fact : >> GET / HTTP/1.1 >> Host: toto >> Connection: close >> >> I don't get it ... HTTP/1.1 says that by default keep-alive is activated >> on every request unless Connection: close is specified. >> If HAProxy sends a Connection: close to HTTP backend, this one will close >> the connection ... >> Do somebody is able to explain why HAProxy sends a Connection: close to >> backend ? >> >> nm. >> >> 2010/3/30 Óscar Frías Barranco <ofr...@gmail.com> >> >> Hello. >>> >>> I have just read Patrik Nilsson email about http-server-close and Jetty. >>> Unfortunately I cannot reply to that email because I read it in the archives >>> and I was not subscribed to the list. >>> >>> We are facing a very similar problem using Tomcat 6.0.20 in the backend >>> (and haproxy 1.4.2). >>> >>> When we go direct (without haproxy) to the backend servers, these are the >>> headers: >>> >>> REQUEST: >>> GET http://ned.trabber.com/es/ HTTP/1.1 >>> Accept: image/gif, image/jpeg, image/pjpeg, application/x-ms-application, >>> application/vnd.ms-xpsdocument, application/xaml+xml, application/x-ms-xbap, >>> application/x-shockwave-flash, */* >>> Accept-Language: es >>> User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.0; >>> Trident/4.0; SLCC1; .NET CLR 2.0.50727; .NET CLR 3.0.30618; .NET CLR >>> 3.5.30729) >>> Accept-Encoding: gzip, deflate >>> Connection: Keep-Alive >>> Host: ned.trabber.com >>> >>> RESPONSE: >>> HTTP/1.1 200 OK >>> Server: Apache-Coyote/1.1 >>> Expires: Thu, 01 Jan 1970 00:00:00 GMT >>> Cache-Control: no-cache >>> Content-Type: text/html;charset=UTF-8 >>> Content-Language: es >>> Transfer-Encoding: chunked >>> Content-Encoding: gzip >>> Vary: Accept-Encoding >>> Date: Tue, 30 Mar 2010 15:49:05 GMT >>> >>> >>> This means that the keep alive is working OK. >>> >>> However, when we go through haproxy, this is the response: >>> >>> HTTP/1.1 200 OK >>> Server: Apache-Coyote/1.1 >>> Expires: Thu, 01 Jan 1970 00:00:00 GMT >>> Cache-Control: no-cache >>> Content-Type: text/html;charset=UTF-8 >>> Content-Language: es >>> Content-Encoding: gzip >>> Vary: Accept-Encoding >>> Date: Tue, 30 Mar 2010 16:11:56 GMT >>> Connection: close >>> >>> >>> So the keepalive is not working in this case. >>> >>> It seems to me that when http-server-close option is enabled, haproxy >>> replaces the original request header "Connection: Keep-Alive" by >>> "Connection: close". And this change is making Tomcat change its behavior: >>> when it receives a "Connection: close" it does not use chunked transfer >>> encoding. Instead, Tomcat replies with a "Connection: close" response >>> header and a non-chunked response whose length is indicated by closing the >>> connection. >>> >>> I verified this by directly sending to the backend server the original >>> request but with "Connection: close" instead of the original "Connection: >>> keep-alive". This is the output: >>> >>> HTTP/1.1 200 OK >>> Server: Apache-Coyote/1.1 >>> Expires: Thu, 01 Jan 1970 00:00:00 GMT >>> Cache-Control: no-cache >>> Content-Type: text/html;charset=UTF-8 >>> Content-Language: es >>> Content-Encoding: gzip >>> Vary: Accept-Encoding >>> Date: Tue, 30 Mar 2010 16:22:19 GMT >>> Connection: close >>> >>> >>> As you can see it is identical to haproxy output. >>> >>> So my questions are: >>> >>> 1) Is http-server-close option only supporting backend servers which use >>> chunked encoding or include a content length header ? As far as I know (but >>> I am not an expert), the behavior of Tomcat is also correct according to the >>> standard, isn't it ? >>> >>> http://www.w3.org/Protocols/rfc2616/rfc2616-sec4.html#sec4.4 (bullet >>> 5) >>> >>> >>> 2) Would it be feasible for haproxy to "convert" the backend server >>> response from "non-chunked" encoding to a chunked response ? >>> >>> >>> Thank you, >>> Óscar >>> >>> >>> >> >
