O problema original foi um problema com regsub(\?(.*),)
, que causou um problema porque o conversor regsub
está limitado a expressões que o analisador de configuração pode manipular - e parênteses não são utilizáveis porque o analisador vê o )
como fechando regsub()
com poucos argumentos. (Para literais, você pode usar \xnn
hex-escapes para contornar as limitações do analisador, mas isso não funcionaria aqui.)
regsub
estava sendo usado porque esse redirecionamento está sendo acionado durante o processamento da resposta if { status 404 }
, e a path
fetch não está disponível nesse estágio de processamento - o HAProxy libera os buffers usados pela solicitação quando ela é enviado para um servidor.
No entanto, o HAProxy 1.6 também introduz variáveis de usuário que podem ser usadas para transportar dados do lado da solicitação, se usados no escopo de transação ( txn
).
Durante o processamento da solicitação, armazene o conteúdo da busca path
em uma variável com escopo de transação chamada (coincidentemente) path
.
http-request set-var(txn.path) path
Em seguida, pode ser acessado durante o processamento da resposta.
O seguinte é mostrado em várias linhas para maior clareza, mas deve estar em uma única linha de configuração.
http-response redirect
location %[var(txn.path),map(/etc/haproxy/redirects.map)]
code 303
if { status 404 } { var(txn.path),map(/etc/haproxy/redirects.map) -m found }
Isso - se o código de status da resposta for 404 - recupera o valor da variável e verifica se ele tem um valor no arquivo de mapeamento. Em caso afirmativo, esse valor é usado para o redirecionamento.