On Sat, Nov 13, 2010 at 10:54:26AM +0800, Hogan Yu wrote:
> Hi Cryil,
>
> Great thanks for you help. I change the nbproc to 1 and it works.
> About you suggestion on the param "option http-server-close" and "option
> httpclose". If i don't config it ,It still works for me. The spec saids:
> By default HAProxy operates in a tunnel-like mode with regards to persistent
> connections: for each connection it processes the first request and forwards
> everything else (including additional requests) to selected server. Once
> established, the connection is persisted both on the client and server sides.
> Use "option http-server-close" to preserve client persistent connections
> while handling every incoming request individually, dispatching them one
> after another to servers, in HTTP close mode. Use "option httpclose" to
> switch both sides to HTTP close mode. "option forceclose" and "option
> http-pretend-keepalive" help working around servers misbehaving in HTTP
> close mode.
>
> It said it processes the first request and follows to on selected server,
> So we don't need to analysis the headers again.
In general, tunnel mode will work. But it's dirty for several reasons :
- when you want to add header rewriting rules, you'll find they randomly
work (only first requests/responses will be affected). This is also true
for the x-forwarded-for header.
- logging will only report the first request
- ACL-based switching rules won't be usable
- the clients uselessly maintain idle connections to the server between
their fetches, which induces a load on the server and prevents them
from being usable by other clients.
You'd really better use "http-server-close" which will still enable client
side keep-alive but close server-side idle connections.
> I set cookie in headers to
> help check which server is selected by follows:
> cookie HTTPERVERID insert nocache indirect
>
> It will set the cookie "HTTPSERVERID=A" for server1 and "HTTPSERVERID=B"
> for server2. If we don't click the link for a long time and the connection
> is timeout, the Haproxy will reanylisis the head and send the request to the
> correct server.
>
> For this browsers that they dont support the cookie. it works same.
>
> does my thougt is correct?
In part, because right now all browsers support cookies and have done
so for the last 10 years at least. Even WAP gateways and terminals do
support cookies. What you may find are browsers where cookie support
has been explicitly disabled. But even then, when users disable cookies,
they normally disable persistent cookies, those that are stored into a
file. Session cookies, such as the cookies haproxy inserts, just live
while the browser window is open and are not stored in any file. Those
ones are almost never blocked.
> I use the
> cookie HTTPERVERID insert nocache indirect
> and
> appsession JSESSIONID len 34 timeout 1h
> together. I use this cookie because I want to HAproxy to forward request to
> correct server when I restart the HAproxy. All the jsessionids mapping with
> backend server in the Haproxy memory will be lost when I restart it and It
> will maybe forward the request to another server.
>
> If the user browser enable supporting of cookie, there will two cookies in
> the user client (HTTPSERVERID and JSESSIONID). does the HAproxy pick the
> HTTPSERVERID first and send the request to the server and not set the
> JSESSIONID into the hash map to the server?
Yes. To be more precise, in the request, haproxy looks for the HTTPSERVERID
and if found and valid, sets the server to match this one. Next, it will
look to the JSESSIONID, and if found and valid and if the server has not
been assigned, it will then be assigned. The two processings are performed
one at a time and are not mutually-exclusive.
Regards,
Willy
