Partilhar via

Solicitações de Entrada de Roteamento

  • Artigo

A API do Servidor HTTP mantém um banco de dados de roteamento para determinar qual aplicativo recebe uma solicitação de entrada. A tabela de roteamento é criada a partir do banco de dados de reserva e contém entradas de reserva, bem como registros atuais. Quando um registro ou reserva é feito, ele é colocado no bucket de banco de dados de roteamento que corresponde ao tipo de host da seguinte maneira:

  • + : os registros de porta são colocados no bucket "Caractere Curinga Forte"

  • host: os registros de porta são colocados no bucket "Explícito"

  • IP: os registros de porta são colocados no bucket "Curinga Fraco associado a IP"

  • * : os registros de porta são colocados no bucket "Curinga Fraco"

Essas etapas também se referem à ordem em que as solicitações HTTP de entrada são processadas. As reservas curinga fortes primeiro, em seguida, a reserva explícita são verificadas seguidas pelo curinga fraco associado a IP e curinga fraco. A pesquisa é interrompida quando uma correspondência é encontrada para que os registros em qualquer um dos buckets restantes não sejam encontrados.

O algoritmo de roteamento da API do Servidor HTTP localiza a melhor correspondência para o UrlPrefix pesquisando as entradas de registro e as entradas de reserva do banco de dados de roteamento, começando com o bucket curinga forte e terminando com o bucket curinga fraco. A melhor correspondência, dentro de um bucket, é a correspondência mais longa na parte de URI relativa do UrlPrefix (supondo uma correspondência exata para as partes de host, porta e esquema da URL). Depois que uma correspondência é encontrada em um bucket, o algoritmo de roteamento interrompe sua pesquisa e ignora todos os buckets de prioridade mais baixa.

Por exemplo, considere os seguintes registros (listados em ordem decrescente de prioridade com base nos tipos de bucket:

  • Registro: https://+:80/vroot/ é registrado pelo aplicativo 1

  • Registro: https://adatum.com:80/ é registrado pelo aplicativo 2

  • Registro: https://\*:80/ é registrado pelo aplicativo 3

Uma solicitação de entrada para https://adatum.com:80/vroot/subdir/file.htm/ é entregue ao aplicativo 1. Uma solicitação de entrada para https://adatum.com:80/default.htm/ é entregue ao aplicativo 2. Uma solicitação de entrada para https://otheradatum.com:80/file.htm/ é entregue ao aplicativo 3.

Se a melhor correspondência for uma entrada de reserva, isso significa que o aplicativo que deve receber a solicitação não está em execução. Por exemplo, considere o seguinte registro e reserva:

  • Registro: https://\*:80/vroot/ é registrado pelo aplicativo 1, usuário A

  • Reserva: https://adatum.com:80/ foi reservada para o usuário B

Uma solicitação de entrada para https://adatum.com:80/vroot/file.htm/ não é entregue ao aplicativo 1 porque a melhor correspondência leva à entrada de reserva para o usuário B. As regras de precedência são aplicadas nesse caso à reserva que tem uma prioridade mais alta. Se nenhum processo estiver ativo autorizado e registrado em solicitações de serviço para a URL recebida, a solicitação será rejeitada com um código de status 400 (Solicitação Incorreta).