>1. One you haven't met yet : your "reqirep" pattern will delete the "/" >at the beginning, which may produce some "400 Bad Request" on the backend.
>Example : >GET /aps_ass_UNIQUE_web1_index.html HTTP/1.1 >will be replaced by >GET index.html HTTP/1.1 reqirep (.*)\/aps_ass_UNIQUE_web[0-9]*_(.*) \1\2 The substitution works well I think... as (.*) comprises also "/" then reporting all after aps_ass_UNIQUE_web[0-9]*_ >2. reqirep is executed *BEFORE* the evaluation of user-server. So the >routing information has already disappeared when it is time to choose a >server with "use-server". Ok. Thanks. There are not so many info on precedence haproxy uses in various stages. >3. Without any other details (please provide a more complete >configuration next time), I assume that you'll meet another issue due to >cookie persistence. You'll probably want to have a look to "force-persist". >Why not choosing a combination of cookie persistence and force-persist >instead of doing some magic with the urls ? How can I do that ? Can you tell me how make an acl that check inserted cookie ? We use cookie ha_aps_srvid insert indirect nocache server web1 192.168.1.50:80 check inter 5s weight 50 cookie web1 server web4 192.168.1.50:80 check inter 5s weight 50 cookie web4 server web10 192.168.1.50:80 check inter 5s weight 50 cookie web10 Roberto -----Original Message----- From: Cyril Bonté [mailto:[email protected]] Sent: mercoledì 29 luglio 2015 16.33 To: mlist; [email protected] Subject: Re: use_server Hi, On 29/07/2015 13:07, mlist wrote: > We have 3 backend servers balanced with haproxy with "cookie insert" option > and ssl redirection. > For our help desk, we need operators can access a specific backend server to > check specific server when we have problems on this backend server. > > We try to do that with the following section, so no hosts file nor DNS > mapping and special binding on backend servers are needed to access specific > backend server, maintaining the right cookie after use_server. > > We have 3 backend servers: web1, web4 and web10. We want to go on: > web1 if in the URL haproxy find " aps_ass_UNIQUE_web1_" -> ex: > http://<mydomain>/app1/aps_ass_UNIQUE_web1_ > web4 if in the URL haproxy find " aps_ass_UNIQUE_web4_" -> ex: > http://<mydomain>/app1/aps_ass_UNIQUE_web4_ > web4 if in the URL haproxy find " aps_ass_UNIQUE_web10_" -> ex: > http://<mydomain>/app1/aps_ass_UNIQUE_web10_ > > Following configuration does not work, can you help to identify a solution ? > > acl aps_ass_web1 path_reg (.*)\/aps_ass_UNIQUE_web1_(.*) > acl aps_ass_web4 path_reg (.*)\/aps_ass_UNIQUE_web4_(.*) > acl aps_ass_web10 path_reg (.*)\/aps_ass_UNIQUE_web10_(.*) > reqirep (.*)\/aps_ass_UNIQUE_web[0-9]*_(.*) \1\2 > use-server web1 if aps_ass_web1 > use-server web4 if aps_ass_web4 > use-server web10 if aps_ass_web10 I see several issues here. 1. One you haven't met yet : your "reqirep" pattern will delete the "/" at the beginning, which may produce some "400 Bad Request" on the backend. Example : GET /aps_ass_UNIQUE_web1_index.html HTTP/1.1 will be replaced by GET index.html HTTP/1.1 2. reqirep is executed *BEFORE* the evaluation of user-server. So the routing information has already disappeared when it is time to choose a server with "use-server". 3. Without any other details (please provide a more complete configuration next time), I assume that you'll meet another issue due to cookie persistence. You'll probably want to have a look to "force-persist". Why not choosing a combination of cookie persistence and force-persist instead of doing some magic with the urls ? -- Cyril Bonté -- Il messaggio e' stato analizzato alla ricerca di virus o contenuti pericolosi da MailScanner, ed e' risultato non infetto.
