Lutando com as ACLs do Haproxy 1.5 usando expressões regulares e parâmetros de URL

Question

Estou usando a configuração do Haproxy 1.5.3 com ssl no frontend e também enviando o ssl para os servidores de backend. o modo é http e usa acls para determinar a aderência.

Minhas solicitações de teste são as seguintes:

1. wget https: //domain.com/ping?IPT=transpor6t&FROM_ADDRESS=409
2. wget https: //domain.com/ping?FROM_ADDRESS=409&IPT=transport6
3. o URL real terá 5 parâmetros diferentes e o FROM_ADDRESS será o 3º parâmetro.

Eu preciso criar pedidos fixos neste 3º Parâmetro e parece haver muitas maneiras de fazer isso usando o Haproxy e mesmo usando o regex é caro, ele nos fornece a maior flexibilidade, então é isso que escolhemos (neste exemplo nós afastou-se do regex para simplificar o problema e decidiu apenas olhar o último caractere do parâmetro, para garantir que o regex não seja o problema.

Nossa configuração de ACL (mais de uma cama de teste para ver se podemos fazer com que ela funcione)

acl block_1 urlp_end(FROM_ADDRESS) 0
acl block_2 urlp_end(FROM_ADDRESS) 9

   use_backend block_1_hosts if block_1
   use_backend block_2_hosts if block_2

backend block_1_hosts
    option httpchk GET /ping
    server s1 s1.domain.com:443 weight 1 maxconn 2000 check ssl verify none inter 2000
    server s2 s2.domain.com:443 weight 1 maxconn 2000 check ssl verify none inter 2000 backup

  backend block_2_hosts
    option httpchk GET /ping
    server s1 s1.domain.com:443 weight 1 maxconn 2000 check ssl verify none inter 2000 backup
    server s2 s2.domain.com:443 weight 1 maxconn 2000 check ssl verify none inter 2000

Com o teste que fizemos, acreditamos que apenas o primeiro parâmetro encontrado na URL pode ser correspondido (ele não pesquisa o restante dos parâmetros). Isso pode ser um bug ou talvez por design (os documentos parecem um pouco ambíguos em torno do urlp, pelo menos para nós), mas faria sentido que você fosse capaz de corresponder todos os parâmetros no URL.

**Test1 - FROM_ADDRESS in the second parameter position fails**
wget https://domain.com/ping?IPT=transpor6t&FROM_ADDRESS=409
haproxy logs:
5.35.250.77:41464 [22/Aug/2014:14:20:49.783] https-in~ https-in/<NOSRV> -1/-1/-1/-1/12 503 212 - - SC-- 0/0/0/0/0 0/0 "GET /ping?IPT=transpor6t HTTP/1.0"

**Test2 - FROM_ADDRESS in the first parameter position passes**
wget https://domain.com/ping?FROM_ADDRESS=409&IPT=transport6
haproxy logs:
5.35.250.77:41465 [22/Aug/2014:14:21:33.763] https-in~ block_2_hosts/rs6 12/0/2/2/16 200 229 - - ---- 0/0/0/0/0 0/0 "GET /ping?FROM_ADDRESS=409 HTTP/1.0"

Eles não deveriam passar com essa ACL? Alguma ideia? Muito Obrigado, Andre

    

Answer 1

Ainda não testei isso, mas tente especificar o delimitador:

acl block_1 urlp_end(FROM_ADDRESS,&) 0
acl block_2 urlp_end(FROM_ADDRESS,&) 9

    

Answer 2

Funciona como foi projetado , receio.

Note that the ACL version of this fetch do[sic!] not iterate over multiple parameters and stop at the first one as well.

Considere usar isso, provavelmente está mais perto do que você quer:

stick on urlp(FROM_ADDRESS)