Enquanto trabalhava em uma expressão regular (regex) para usar com o NGINX, tive uma ideia de uma maneira de testar facilmente uma regex dentro de uma configuração real do NGINX. (O testador de regex funciona da mesma forma para NGINX Open Source e NGINX Plus , e para facilitar a leitura, vou me referir simplesmente ao NGINX neste post.)
O suporte para expressões regulares é um dos recursos poderosos do NGINX, mas as expressões regulares podem ser complexas e difíceis de acertar, especialmente se você não trabalha com elas regularmente. O NGINX permite expressões regulares em várias partes de uma configuração, por exemplo, locais, mapas, reescritas e nomes de servidores. O testador descrito aqui é para expressões regulares em locais e mapas.
Existem outros testadores de regex online gratuitos que são bons para a maioria das regexes, mas o NGINX usa alguns atalhos não padronizados otimizados para aplicativos da web. Por exemplo, você não precisa escapar da barra (/) em um URI como faz em uma regex padrão. Além disso, ao usar uma regex em um mapa, você especifica qual valor definir com base em uma correspondência. Com outros testadores de regex, talvez seja necessário modificar o regex ou, no caso de um mapa, inferir qual valor será definido. Além disso, é sempre bom poder testar uma regex com o mecanismo de regex real no ambiente real.
Notas:
O NGINX usa Perl Compatible Regular Expressions (PCRE), e esta postagem pressupõe um conhecimento básico do NGINX e de expressões regulares. Explicar como construir regexes está fora do escopo deste post, e lamentamos não poder responder mais perguntas na seção de comentários sobre como fazer isso.
Existem vários sites que fornecem ferramentas ou documentação para criar expressões regulares. Duas que achamos úteis são:
O testador manipula expressões regulares em dois contextos – blocos map{}
e blocos HTTP location{}
– e abaixo há uma breve discussão sobre como as expressões regulares funcionam em cada caso. Explicar como o NGINX lida com expressões regulares em todos os contextos está fora do escopo deste post; veja nossa documentação:
Verificações de saúde:
location{}
– Guia de administração do nginx.org e NGINX Plusmap{}
– nginx.orgAntes de entrarmos nos detalhes do testador de regex, vamos primeiro discutir como as regexes podem ser usadas em locais e mapas NGINX.
Expressões regulares em blocos NGINX location{}
são do formato:
localização regex { #... }
Por exemplo, um bloco location{}
com a seguinte regex manipula todas as solicitações PHP com um URI terminando com myapp/ filename .php , como /test/myapp/hello.php e /myapp/hello.php . O asterisco após o til ( ~*
) torna a correspondência insensível a maiúsculas e minúsculas.
localização ~* /myapp/.+\.php$ {
#...
}
O NGINX e o testador de regex oferecem suporte a grupos de captura posicional em blocos location{}
. No exemplo a seguir, o primeiro grupo captura tudo antes do nome do arquivo PHP e o segundo captura o nome do arquivo PHP:
localização ~* (.*/myapp)/(.+\.php)$ {
#...
}
Para o URI /myapp/hello.php , a variável $1
é definida como /myapp
e $2
é definida como hello.php
.
O NGINX também oferece suporte a grupos de captura nomeados:
localização ~* (?<início>.*myapp)/(?<fim>.+\.php)$ {
#...
}
Neste caso, a variável $begin
é definida como /myapp
e $end
é definida como hello.php
.
O testador de regex suporta grupos de captura nomeados, mas os trata como grupos de captura posicionais em sua saída, exibindo seus números ordinais em vez de nomes.
Os blocos NGINX map{}
que usam expressões regulares têm o formato:
map variável-para-testar variável-para-definir { regex1 valor-para-definir-se-corresponder ; regex2 valor-para-definir-se-corresponder ; #... regexN valor-para-definir-se-corresponder ; padrão valor-para-definir-se-não-corresponder ; }
Por exemplo, este bloco map{}
define a variável $isphp
para1
se o URI (conforme registrado na variável $uri
) termina em .php , e0
se não (a correspondência diferencia maiúsculas de minúsculas):
mapa $uri $isphp {
~\.php$ 1;
padrão 0;
}
Para mapas, o NGINX e o testador de regex oferecem suporte a grupos de captura posicionais e nomeados.
Por exemplo, os mapas a seguir definem a variável $fileext
para o valor da extensão do arquivo, que também é capturada como $1
neste exemplo:
map $uri $fileext { ~*.+\.(.+)$ $1;
padrão '';
}
E como $ext
neste exemplo:
mapa $uri $fileext {
~*.+\.(?<ext>.+)$ $ext;
padrão '';
}
Você pode usar o testador de regex para blocos map{}
nos contextos http{}
e stream{}
, porque a sintaxe e o comportamento dos mapas são os mesmos em ambos os contextos. Observe, no entanto, que se o seu mapa estiver no contexto stream{}
, você poderá usar apenas o bloco map{}
da saída do testador. Veja a nota abaixo para mais detalhes.
O testador de regex é implementado em um contêiner Docker com NGINX e NGINX Unit instalados. A unidade NGINX oferece duas variações de uma página PHP, uma para expressões regulares em blocos location{}
e a outra para expressões regulares em blocos map{}
. As duas páginas solicitam ao usuário entradas diferentes:
Página de localização:
Página do mapa:
map
)do mapa
Após fornecer as informações, clique no botão Testar . O testador gera o arquivo de configuração NGINX necessário, a configuração é recarregada e uma solicitação é enviada para testar o regex. Os resultados são então exibidos e indicam se uma correspondência foi encontrada. Se sim, na página do Location Tester os valores dos grupos de captura são exibidos e na página do Map Tester o valor definido pelo mapa é informado.
Este exemplo mostra os resultados de um teste que não diferencia maiúsculas de minúsculas da expressão regular (.*myapp)/(.+\.php)$
em relação ao URI /myapp/hello.php :
Este exemplo mostra os resultados de um teste que não diferencia maiúsculas de minúsculas da expressão regular .+\.(?<ext>.*)$
contra o valor /meuaplicativo/olá.php, com o grupo de captura nomeado $ext
como o valor a ser definido:
Observação: Se o seu mapa estiver no contexto stream{}
, você poderá usar apenas o bloco map{}
da saída na sua configuração. O bloco server{}
não é válido porque inclui um bloco location{}
, que não é suportado no contexto stream{}
.
Você pode ver que a configuração do NGINX é bem curta e simples. O trabalho pesado é feito pela página PHP que gera o arquivo de configuração NGINX necessário com base nos valores inseridos pelo usuário, recarrega o NGINX, envia uma solicitação ao NGINX e exibe os resultados.
Você pode testar o testador de regex por si mesmo: todo o código está disponível em nosso repositório GitHub ( https://github.com/nginxinc/NGINX-Demos/tree/master/nginx-regex-tester ).
Para facilitar a instalação e execução do testador de regex, todos os arquivos necessários estão incluídos. Para construir a imagem do Docker e construir o contêiner, basta executar:
$ docker-compose up -d
Em seguida, direcione seu navegador para http:// Docker-host /regextester.php .
Espero que o testador seja útil ao usar expressões regulares e que ele lhe dê uma ideia do poder, flexibilidade e simplicidade do NGINX.
Para experimentar o testador de regex com o NGINX Plus, comece hoje mesmo seu teste gratuito de 30 dias ou entre em contato conosco para discutir seus casos de uso .
"Esta postagem do blog pode fazer referência a produtos que não estão mais disponíveis e/ou não têm mais suporte. Para obter as informações mais atualizadas sobre os produtos e soluções F5 NGINX disponíveis, explore nossa família de produtos NGINX . O NGINX agora faz parte do F5. Todos os links anteriores do NGINX.com redirecionarão para conteúdo semelhante do NGINX no F5.com."