UrlPrefix Strings

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

Formato UrlPrefix

Um UrlPrefix tem a seguinte sintaxe:

"scheme://host:port/relativeURI"

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

regime

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

anfitrião

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 de host é especificada, um UrlPrefix se enquadra em uma das quatro categorias de roteamento a seguir, que são descritas com mais detalhes abaixo:

Curinga forte

Explícito

Curinga fraco vinculado a IP

Curinga fraco

porto

Uma cadeia 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 ("/"). Esta é uma cadeia de caracteres de prefixo que indica uma subárvore dentro do namespace da máquina 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 devidamente formados são:

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

Host-Specifier Categorias

Para flexibilidade e facilidade de uso, a API do Servidor HTTP suporta quatro maneiras diferentes de especificar hosts. As quatro categorias de especificador de host estã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 cai na categoria curinga forte.

Um curinga forte é útil quando um aplicativo precisa atender a solicitações endereçadas a um ou mais URIs relativos, independentemente de como essas solicitações chegam à máquina ou do site especificado em seus cabeçalhos de 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ícito

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 de host é comparado diretamente com os cabeçalhos de host de solicitações de entrada.

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

curinga fraco vinculado a IP

Quando um endereço IP aparece como o elemento host, o UrlPrefix cai na categoria Weak Wildcard vinculado a IP. Esse tipo de UrlPrefix corresponde a qualquer nome de host para a interface IP especificada com o esquema, porta e relativeURI especificados, e que ainda não foi correspondido por um curinga forte ou UrlPrefix explícito. O endereço IP assume 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 0-255, como 192.168.0.0.

Cadeia de caracteres literal IPv6

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

Os especificadores de host curinga fraco vinculado a IP destinam-se a aplicativos que variam o conteúdo que eles servem com base na rota tomada pelas solicitações de entrada. Não confie em especificadores de host curinga fraco ligados a IP para impor a segurança.

Curinga fraco (asterisco)

Quando um asterisco (*) aparece como o elemento host, o UrlPrefix cai na categoria curinga fraca. Esse tipo de UrlPrefix corresponde a qualquer nome de host associado ao esquema, porta e relativeURI especificado que ainda não tenha sido correspondido por um UrlPrefix curinga forte, explícito ou vinculado 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 de namespace de URL sem ter que usar muitos UrlPrefixes.

Deteção de conflito UrlPrefix durante a 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 eles estejam em categorias diferentes. Apenas dentro da mesma categoria um conflito faz com que uma tentativa de reserva falhe.

Por exemplo, seria possível reservar tanto o https://www.adatum.com:80/vroot/ UrlPrefix explícito quanto o curinga forte e conflitante UrlPrefix https://+:80/vroot/, uma vez que pertencem a categorias diferentes. No entanto, uma tentativa subsequente de reservar https://+:80/vroot/ a um utilizador diferente falharia porque entraria em conflito com uma reserva existente na 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 um registro de prioridade mais baixa possa pegar solicitações que não são destinadas a ele. O status na falha é 400 ("Solicitação incorreta") em vez de 503 ("Serviço não disponível"), porque um retorno 503 às vezes é erroneamente interpretado 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ções 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. Em resumo, a ordem pela qual as categorias são examinadas é a seguinte:

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

Se nenhuma correspondência for encontrada em qualquer uma das categorias, a API do Servidor HTTP enviará uma resposta com um código de 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 por mais tempo. Por exemplo, suponha que os dois UrlPrefixes a seguir sejam 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 de https://www.adatum.com:80/default.htm para a Fila1 e uma solicitação de https://www.adatum.com:80/dir/sna/snadefault.htm para a Fila2. Ele roteia uma solicitação de https://www.adatum.com:80/dir/app.htm para 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.