Como as solicitações são correspondentes a uma configuração de rota

  • Artigo

Uma rota no Azure Front Door define como o tráfego é tratado quando a solicitação recebida chega à borda do Azure Front Door. Através das configurações de rota, uma associação é definida entre um domínio e um grupo de origem. Usando recursos avançados, como Padrão de Correspondência e Conjuntos de regras , você pode ter controle granular sobre o tráfego para seus recursos de back-end.

Observação

Ao usar os conjuntos de regras do Front Door, você pode configurar uma regra para substituir o grupo de origem de uma solicitação. O grupo de origem definido pelo conjunto de regras substitui o processo de roteamento descrito neste artigo.

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 Standard ou Premium do Azure Front Door até março de 2027. Para obter mais informações, consulte Desativação do Azure Front Door (clássico).

Quando uma solicitação chega à borda do Azure Front Door (Clássico), uma das primeiras coisas que o Front Door faz é determinar como rotear a solicitação correspondente para um recurso de back-end e, em seguida, executar uma ação definida na configuração de roteamento. O documento a seguir explica como o Front Door determina qual configuração de rota usar ao processar uma solicitação.

Estrutura de uma configuração de rota do Front Door

Uma regra de roteamento do Front Door é composta de duas partes principais, o "lado esquerdo" e o "lado direito". O Front Door faz a correspondência da solicitação de entrada com o lado esquerdo da rota, enquanto o lado direito define como a solicitação é processada.

Correspondência de entrada (lado esquerdo)

As propriedades a seguir determinam se a solicitação de entrada corresponde à regra de roteamento (ou lado esquerdo):

  • Protocolos HTTP - HTTP ou HTTPS
  • Domínio: por exemplo: www.foo.com, *.bar.com
  • Caminhos: por exemplo: /*, /users/*, /file.gif

Essas propriedades são expandidas internamente para que cada combinação de Protocolo/Domínio/Caminho seja um possível conjunto de correspondências.

Decisão de roteamento (lado direito)

A decisão de como processar a solicitação depende do fato de o cache estar habilitado para a rota. Se uma resposta em cache não estiver disponível, a solicitação será encaminhada para a origem apropriada.

Correspondência de rotas

Essa seção se concentra em como o Front Door corresponde a uma regra de roteamento. O conceito básico é que o Front Door sempre corresponda à solicitação mais específica olhando apenas para o “lado esquerdo”. O Front Door faz a primeira correspondência com base no protocolo, depois no domínio e, por último, no caminho.

Correspondência do host de front-end

O Azure Front Door utiliza a seguinte lógica para corresponder aos hosts de front-end:

  1. Determine se há alguma rota com uma correspondência exata no host do front-end.
  2. Se não houver correspondência exata entre os hosts do front-end, a solicitação será rejeitada e um erro 400: Solicitação Incorreta será enviado.

As tabelas a seguir mostram três regras de roteamento diferentes com host e caminhos de front-end:

Regra de roteamento Hosts de front-end Caminho
Um foo.contoso.com /*
B foo.contoso.com /users/*
C www.fabrikam.com, foo.adventure-works.com /*, /images/*

A tabela a seguir mostra os resultados de correspondência para as regras de roteamento acima:

Host de front-end de entrada Regras de roteamentos com correspondência
foo.contoso.com A, B
www.fabrikam.com C
images.fabrikam.com Erro 400: solicitação inválida
foo.adventure-works.com C
contoso.com Erro 400: solicitação inválida
www.adventure-works.com Erro 400: solicitação inválida
www.northwindtraders.com Erro 400: solicitação inválida

Correspondência de caminho

Depois que o Front Door determina o host de front-end e os filtros específicos para possíveis regras de roteamento, o Front Door seleciona as regras de roteamento com base no caminho da solicitação. Uma lógica semelhante à dos hosts de front-end é usada para corresponder ao caminho da solicitação:

  1. Determine se há alguma regra de roteamento com uma correspondência exata para o caminho da solicitação.
  2. Se não houver um caminho exato de correspondência, o Front Door procurará uma regra de roteamento com um caminho curinga que correspondente.
  3. Se não forem encontradas regras de roteamento com um caminho correspondente, a solicitação será rejeitada e um erro 400: Solicitação Incorreta será enviado.

Observação

O * de caracteres curinga só é válido para caminhos que não tenham outros caracteres depois dele. Além disso, o caractere curinga * deve ser precedido por uma barra /. Caminhos sem curinga são considerados caminhos de correspondência exata. Um caminho que termina em uma barra / também é um caminho de correspondência exata. Certifique-se de que seus caminhos sigam essas regras para evitar erros.

Observação

  • Quaisquer caminhos sem um caractere curinga são considerados caminhos de correspondência exata. Se um caminho terminar em /, isso será considerado uma correspondência exata.
  • Os caminhos dos padrões de correspondência não diferenciam maiúsculas de minúsculas, o que significa que caminhos com maiúsculas e minúsculas diferentes são tratados como duplicatas. Por exemplo, o mesmo host usa o mesmo protocolo com os caminhos /FOO e /foo. Esses caminhos são considerados duplicatas, o que não é permitido na configuração dos padrões de correspondência.

A tabela a seguir é uma lista de regras de roteamento, combinação de host front-end e caminho:

Regra de roteamento Host de front-end Caminho
Um www.contoso.com /
B www.contoso.com /*
C www.contoso.com /ab
D www.contoso.com /abc
E www.contoso.com /abc/
F www.contoso.com /abc/*
G www.contoso.com /abc/def
H www.contoso.com /path/

A tabela a seguir mostra com qual regra de roteamento a solicitação recebida corresponde ao chegar à borda da Front Door:

Solicitação de entrada Rota correspondente
www.contoso.com/ Um
www.contoso.com/a B
www.contoso.com/ab C
www.contoso.com/abc D
www.contoso.com/abzzz B
www.contoso.com/abc/ E
www.contoso.com/abc/d F
www.contoso.com/abc/def G
www.contoso.com/abc/defzzz F
www.contoso.com/abc/def/ghi F
www.contoso.com/path B
www.contoso.com/path/ H
www.contoso.com/path/zzz B

Aviso

Se não houver regras de roteamento para um host de front-end de correspondência exata com um Caminho de rota catch-all (/*), não haverá uma correspondência com nenhuma regra de roteamento.

Exemplo de configuração:

Rota Host Caminho
Um profile.contoso.com /api/*

Tabela de correspondência:

Solicitação de entrada Rota correspondente
profile.domain.com/other Nenhum. Erro 400: solicitação inválida

Decisão de roteamento

Depois que o Front Door faz a correspondência com uma única regra de roteamento, ele precisa escolher como processar a solicitação. Se o Azure Front Door tiver uma resposta em cache disponível para a regra de roteamento correspondente, a solicitação será enviada de volta para o cliente.

Por fim, o Azure Front Door avalia se você tem ou não um conjunto de regras configurado para a regra de roteamento correspondente. Se nenhum conjunto de regras for definido, a solicitação será encaminhada para o grupo de origem sem nenhuma alteração. Caso contrário, os conjuntos de regras serão processados na ordem configurada. Os conjuntos de regras podem substituir uma rota forçando o tráfego para um grupo de origem específico.

Se o Front Door (clássico) não tiver uma resposta em cache para a regra de roteamento correspondente, ele avaliará se a reescrita da URL está configurada para a regra de roteamento correspondente. Se não houver um caminho de encaminhamento personalizado, a solicitação será encaminhada para o back-end apropriado no pool de back-end configurado sem alterações. Se um caminho de encaminhamento personalizado tiver sido definido, o caminho da solicitação será atualizado conforme definido em caminho do encaminhamento personalizado e, em seguida, encaminhado para o back-end.

Próximas etapas