Re: haproxy-1.4.3 and keep-alive status

From: Willy Tarreau <w#1wt.eu>
Date: Mon, 26 Apr 2010 15:58:05 +0200


On Mon, Apr 26, 2010 at 05:53:28PM +0400, Dmitry Sivachenko wrote:
> On Mon, Apr 26, 2010 at 03:41:03PM +0200, Cyril Bont? wrote:
> > Hi Dmitry,
> >
> > Le lundi 26 avril 2010 13:57:12, Dmitry Sivachenko a ?crit :
> > > When I put that server behind haproxy (version 1.4.4) I see the following:
> > >
> > >
> > > 1) GET <some URL> HTTP/1.1
> > > Host: host.pp.ru
> > > User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.3) Gecko/2010041
> > > 4 Firefox/3.6.3
> > > Accept: text/javascript, application/javascript, */*
> > > Accept-Language: en-us,ru;q=0.7,en;q=0.3
> > > Accept-Encoding: gzip,deflate
> > > Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
> > > Keep-Alive: 115
> > > Connection: keep-alive
> > >
> > > 2)
> > > HTTP/1.1 200 OK
> > > Date: Mon, 26 Apr 2010 11:45:01 GMT
> > > Expires: Mon, 26 Apr 2010 11:46:01 GMT
> > > Content-Type: text/javascript; charset=utf-8
> > > Connection: Close
> > >
> > > <some data>
> > >
> > > I have
> > > mode http
> > > option http-server-close
> > > option http-pretend-keepalive
> > >
> > > in my config (tried both with and without http-pretend-keepalive).
> > >
> > > Can you please explain in more detail what server makes wrong and why haproxy
> > > adds Connection: Close header
> > > (and why Firefox successfully uses HTTP keep-alive with the same server without
> > > haproxy).
> >
> > HAProxy can't accept the connection to be keep-alived as it doesn't provide a Content-Length (nor the communication allows chunked transfer).
> > Try to add a Content-Length header equal to your data length and Keep-Alive should be accepted.
> >
>
> Okay, I'll try, thanks for suggestion.
>
> By the way: why haproxy behaves that way? What is the technical problem to
> allow HTTP keep-alive with chunked transfer?

It *does* allow it. It's just that in your case, when your server is behind haproxy, it does *not* send chunked encoding. Look again at your server's response, there is no "transfer-encoding" header, so it is impossible for haproxy or the client to find the end of response.

> AFAIK last chunk is specially
> formed to indicate the end of data so haproxy should see the end of transmitted
> data without Content-Length header?

Yes exactly, that's why it would be nice to get it :-)

Willy Received on 2010/04/26 15:58

This archive was generated by hypermail 2.2.0 : 2010/04/26 16:00 CEST