Cadeias de caracteres de UrlPrefix

  • Artigo

Na API do Servidor HTTP, um UrlPrefix é uma cadeia de caracteres unicode de caractere largo (UTF-16) com um formulário canônico que especifica uma seção do namespace de URL. Ele é usado para reservar uma seção do namespace de URL para uma conta de usuário ou registrar uma seção do namespace de URL para um processo.

Formato UrlPrefix

Um UrlPrefix tem a seguinte sintaxe:

"scheme://host:port/relativeURI"

Os elementos de esquema, host e porta de um UrlPrefix devem estar presentes e não vazios e devem obedecer às seguintes regras:

Esquema

Deve ser http ou https, tudo em letras minúsculas.

Host

Deve ser um nome de domínio totalmente qualificado, uma cadeia de caracteres literal IPv4 ou IPv6 ou um curinga. Ao contrário do esquema, que deve ser minúsculo, a parte do host não diferencia maiúsculas de minúsculas. Dependendo de como sua parte do host é especificada, um UrlPrefix se enquadra em uma das quatro categorias de roteamento a seguir, que são descritas em mais detalhes abaixo:

Curinga forte
Explícita
Curinga fraco associado a IP
Curinga fraco

Porta

Uma cadeia de caracteres numérica decimal que não começa com zero e que representa um número de porta TCP válido (1 a 65.535). Esse valor não pode ser um curinga.

Relativeuri

O elemento relativeURI é opcional, mas se presente deve ser sempre seguido por um caractere de barra ("/"). Essa é uma cadeia de caracteres de prefixo que indica uma subárvore no namespace do computador especificado em relação aos valores de esquema, host e porta. Ao contrário do esquema, que deve ser minúsculo, a parte relativeURI não diferencia maiúsculas de minúsculas.

Exemplos de UrlPrefixes formados corretamente são:

  • https://www.adatum.com:80/vroot/
  • https://adatum.com:443/secure/database/
  • https://+:80/vroot/

Categorias de Host-Specifier

Para flexibilidade e facilidade de uso, a API do servidor HTTP dá suporte a quatro maneiras diferentes de especificar hosts. As quatro categorias do especificador de host são listadas abaixo em ordem de precedência:

Curinga forte (Sinal de Adição)

Quando o elemento host de um UrlPrefix consiste em um único sinal de adição (+), o UrlPrefix corresponde a todos os nomes de host possíveis no contexto de seu esquema, porta e elementos relativeURI e se enquadra na categoria curinga forte.

Um curinga forte é útil quando um aplicativo precisa atender às solicitações endereçadas a uma ou mais relativeURIs, independentemente de como essas solicitações chegam no computador ou em qual site elas especificam em seus cabeçalhos host. O uso de um curinga forte nessa situação evita a necessidade de especificar uma lista exaustiva de endereços IP e/ou host.

Explícita

Um nome de host explícito, como um nome de domínio totalmente qualificado no elemento host, coloca um UrlPrefix na categoria explícita. Esse tipo de elemento host é correspondido diretamente com os cabeçalhos host de solicitações de entrada.

Especificações explícitas de host são úteis para aplicativos de vários sites, como servidores Web que fornecem conteúdo diferente, dependendo do site para o qual a solicitação foi direcionada.

Curinga fraco associado a IP

Quando um endereço IP aparece como o elemento host, o UrlPrefix se enquadra na categoria Curinga Fraco associada a IP. Esse tipo de UrlPrefix corresponde a qualquer nome de host para a interface IP especificada com o esquema, a porta e o relativeURI especificados, e que ainda não foi correspondido por um UrlPrefix forte ou explícito. O endereço IP usa uma das duas formas no elemento host:

Cadeia de caracteres literal IPv4

Um literal IPv4 consiste em quatro números decimais pontilhados, cada um no intervalo de 0 a 255, como 192.168.0.0.

Cadeia de caracteres literal IPv6

Uma cadeia de caracteres literal IPv6 é colocada entre colchetes e contém números hexadecimais separados por dois-pontos; por exemplo: [::1] ou [3ffe:ffff::6ECB:0101].

Os especificadores de host weak-wildcard associados a IP destinam-se a aplicativos que variam o conteúdo que eles atendem com base na rota feita por solicitações de entrada. Não confie em especificadores de host weak-wildcard associados a IP para impor a segurança.

Curinga fraco (asterisco)

Quando um asterisco (*) aparece como o elemento host, o UrlPrefix se enquadra na categoria curinga fraca. Esse tipo de UrlPrefix corresponde a qualquer nome de host associado ao esquema, porta e relativeURI especificados que ainda não foram correspondidos por um UrlPrefix de caractere curinga forte, explícito ou curinga associado a IP.

Essa especificação de host pode ser usada como um catch-all padrão em algumas circunstâncias ou pode ser usada para especificar uma grande seção do namespace de URL sem precisar usar muitos UrlPrefixes.

Detecção de conflito urlPrefix durante reserva e registro

Para fins de reserva e registro, as quatro categorias diferentes de UrlPrefix são tratadas separadamente, sem referência umas às outras. É possível registrar UrlPrefixes conflitantes, desde que estejam em categorias diferentes. Somente dentro da mesma categoria um conflito faz com que uma tentativa de reserva falhe.

Por exemplo, seria possível reservar o UrlPrefix https://www.adatum.com:80/vroot/ explícito e o urlPrefix https://+:80/vroot/curinga forte conflitante, uma vez que pertencem a categorias diferentes. No entanto, uma tentativa subsequente de reservar https://+:80/vroot/ para um usuário diferente falharia porque entraria em conflito com uma reserva existente em sua própria categoria.

Comportamento de roteamento

Ao rotear uma solicitação HTTP de entrada, a API do servidor HTTP começa com a categoria curinga forte e compara a URL de entrada com urlPrefixes registrados e reservados nessa categoria.

Se a URL de entrada corresponder a uma reserva, mas não a um registro, a API do servidor HTTP falhará na solicitação. Isso impede que os registros de prioridade mais baixa possam captar solicitações não destinadas a ele. O status em caso de falha é 400 ("Solicitação Incorreta") em vez de 503 ("Serviço não disponível"), porque um retorno 503 às vezes é interpretado erroneamente por gateways de balanceamento de carga como indicando que o servidor estava sobrecarregado.

Se um registro correspondente for encontrado dentro da categoria, a solicitação será roteada para a fila de solicitação associada a esse registro. A solicitação sempre é roteada para a fila associada ao UrlPrefix correspondente mais longo dentro de uma categoria.

Se nenhuma correspondência for encontrada na categoria, a API do servidor HTTP prosseguirá para a categoria explícita e repetirá o mesmo procedimento. Para resumir, a ordem na qual as categorias são examinadas é a seguinte:

  1. Curinga forte
  2. Explícita
  3. IP-Bound curinga fraco
  4. Curinga fraco

Se nenhuma correspondência for encontrada em nenhuma das categorias, a API do servidor HTTP enviará uma resposta com um código status de 400 para indicar que a solicitação não pode ser roteada.

Regra de correspondência mais longa

Dentro de cada categoria UrlPrefix, a API do Servidor HTTP roteia uma solicitação para a fila associada ao UrlPrefix correspondente mais longo. Por exemplo, suponha que os dois UrlPrefixes a seguir estejam registrados em filas diferentes:

  • Queue1 https://www.adatum.com:80/
  • Queue2 https://www.adatum.com:80/dir/sna/

A API do servidor HTTP roteia uma solicitação para https://www.adatum.com:80/default.htm Queue1 e uma solicitação para https://www.adatum.com:80/dir/sna/snadefault.htm Queue2. Ele roteia uma solicitação para https://www.adatum.com:80/dir/app.htm Queue1 porque a correspondência completa mais longa é com o https://www.adatum.com:80/ UrlPrefix, não com o https://www.adatum.com:80/dir/sna UrlPrefix.