Reconfiguração de URL
O Azure Front Door fornece suporte para reescrita de URL, permitindo modificar o caminho da solicitação que está sendo roteado para sua origem. Esse recurso poderoso permite definir condições que determinam quando o URL ou os cabeçalhos especificados devem ser reescritos. Essas condições baseiam-se nas informações presentes na solicitação e na resposta.
Ao usar a reescrita de URL, você pode redirecionar seus usuários finais para diferentes origens com base em fatores como o tipo de dispositivo ou o tipo de arquivo que estão solicitando. A ação de reescrita de URL pode ser facilmente configurada dentro do conjunto de regras, fornecendo a você um controle refinado sobre seu comportamento de roteamento.
Padrão de origem
O padrão de origem representa o caminho da URL na solicitação inicial que você deseja substituir. Atualmente, o padrão de origem utiliza uma abordagem de correspondência baseada em prefixo. Para corresponder a todos os caminhos de URL, você pode especificar uma barra (/) como o valor do padrão de origem.
No contexto de uma ação de reescrita de URL, apenas o caminho após os patterns para corresponder na configuração da rota é levado em consideração para o padrão de origem. Por exemplo, o conjunto de regras considera apenas /source-pattern como o padrão de origem a ser reescrito se você tiver um formato de URL de entrada igual a contoso.com/pattern-to-match/source-pattern. Após a reescrita do URL ser aplicada, o formato do URL de saída será contoso.com/pattern-to-match/destination.
Nos casos em que você precisa remover o segmento /pattern-to-match da URL, você pode definir o caminho de origem para o grupo de origem na configuração da rota como /.
Destino
O caminho de destino representa o caminho que substitui o padrão de origem. Por exemplo, se o caminho do URL da solicitação for contoso.com/foo/1.jpg e o padrão de origem for /foo/, especificar o destino como /bar/ resulta no conteúdo sendo veiculado de contoso.com/bar/1.jpg a partir da origem.
Preservar caminho sem correspondência
Preservar caminho sem correspondência permite controlar como o caminho restante após o padrão de origem é tratado. Ao definir preserve caminho incompatível como Sim, o caminho restante é anexado ao novo caminho. Por outro lado, defini-lo como Não (padrão) removerá o caminho restante após o padrão de origem.
Aqui está um exemplo que mostra o comportamento de preservar caminho sem correspondência:
| Preservar caminho sem correspondência | Padrão de origem | Destino | Solicitação de entrada | Conteúdo servido a partir da origem |
|---|---|---|---|---|
| Sim | / | /foo/ | contoso.com/sub/1.jpg | /foo/sub/1.jpg |
| Sim | /sub/ | /foo/ | contoso.com/sub/image/1.jpg | /foo/image/1.jpg |
| Não | /sub/ | /foo/2.jpg | contoso.com/sub/image/1.jpg | /foo/2.jpg |
Importante
O Azure Front Door (clássico) será desativado em 31 de março de 2027. Para evitar qualquer interrupção do serviço, é importante que você migre seus perfis do Azure Front Door (clássico) para a camada Azure Front Door Standard ou Premium até março de 2027. Para obter mais informações, consulte Desativação do Azure Front Door (clássico).
O Azure Front Door (clássico) fornece suporte para reescrita de URL configurando um Caminho de encaminhamento personalizado ao configurar a regra de tipo de roteamento de encaminhamento. Por padrão, se apenas uma barra (/*) for definida, o Front Door replica o caminho da URL de entrada na solicitação encaminhada. O cabeçalho do host usado na solicitação encaminhada é baseado na configuração do back-end selecionado. Para obter informações mais detalhadas, veja a documentação Cabeçalho de host de back-end.
O principal aspecto da reescrita de URL reside na capacidade de copiar qualquer parte correspondente do caminho de entrada para o caminho encaminhado ao usar um caminho de encaminhamento personalizado com uma correspondência curinga. A tabela a seguir ilustra um exemplo de uma solicitação recebida e o caminho encaminhado correspondente ao utilizar um caminho de encaminhamento personalizado de /fwd/. A seção indicada como a/b/c representa a parte que substitui a correspondência curinga.
| Caminho da URL de entrada | Caminho da correspondência | Caminho de encaminhamento personalizado | Caminho encaminhado |
|---|---|---|---|
| /foo/a/b/c | /foo/* | /fwd/ | /fwd/a/b/c |
Exemplo de regeneração de URL
Considere uma regra de roteamento com a seguinte combinação de hosts de front-end e caminhos configurados:
| Hosts | Caminhos |
|---|---|
| www.contoso.com | /* |
| /foo | |
| /foo/* | |
| /foo/bar/* |
A tabela a seguir ilustra exemplos de solicitações recebidas e suas rotas correspondentes mais específicas. Ele também fornece exemplos de caminhos de encaminhamento personalizados e os caminhos encaminhados resultantes.
Por exemplo, considere a segunda linha da tabela. Se a solicitação recebida for www.contoso.com/sub e o caminho de encaminhamento personalizado estiver definido como /, o caminho encaminhado será /sub. No entanto, se o caminho de encaminhamento personalizado estiver definido como /fwd/, o caminho encaminhado será /fwd/sub. As partes enfatizadas dos caminhos indicam as partes que fazem parte da correspondência curinga
| Solicitação de entrada | Caminho de correspondência mais específica | / | /fwd/ | /foo/ | /foo/bar/ |
|---|---|---|---|---|---|
| www.contoso.com/ | /* | / | /fwd/ | /foo/ | /foo/bar/ |
| www.contoso.com/sub | /* | /sub | /fwd/sub | /foo/sub | /foo/bar/sub |
| www.contoso.com/a/b/c | /* | /a/b/c | /fwd/a/b/c | /foo/a/b/c | /foo/bar/a/b/c |
| www.contoso.com/foo | /foo | / | /fwd/ | /foo/ | /foo/bar/ |
| www.contoso.com/foo/ | /foo/* | / | /fwd/ | /foo/ | /foo/bar/ |
| www.contoso.com/foo/bar | /foo/* | /bar | /fwd/bar | /foo/bar | /foo/bar/bar |
Observação
O Azure Front Door (clássico) só tem suporte à reescrita de URL de um caminho estático para outro caminho estático. A preservação de um caminho sem correspondência é suportada pelo Azure Front Door Standard e Premium. Para obter mais informações, confira Preservar o caminho sem correspondência.
Configurações opcionais
Configuração do cache: se estiver desabilitado ou não especificado, as solicitações que correspondem a essa regra de roteamento não tentarão usar conteúdo em cache e, em vez disso, sempre buscarão no back-end. Para obter mais informações, confira armazenamento em cache com o Azure Front Door.
Próximas etapas
- Saiba como Criar um perfil do Azure Front Door.
- Saiba mais sobre o conjunto de regras do Azure Front Door
- Saiba mais sobre a arquitetura de roteamento do Azure Front Door.