Chaînes UrlPrefix

Dans l’API de serveur HTTP, un UrlPrefix est une chaîne Unicode à caractères larges (UTF-16) avec une forme canonique qui spécifie une section de l’espace de noms d’URL. Il est utilisé pour réserver une section d’espace de noms d’URL pour un compte d’utilisateur ou pour inscrire une section de l’espace de noms d’URL pour un processus.

UrlPrefix Format

Un UrlPrefix a la syntaxe suivante :

« scheme://host:port/relativeURI »

Les éléments de schéma, d’hôte et de port d’un UrlPrefix doivent être présents et non vides, et doivent respecter les règles suivantes :

Régime

Doit être http ou https, tout en minuscules.

Hôte

Il doit s’agir d’un nom de domaine complet, d’une chaîne littérale IPv4 ou IPv6 ou d’un caractère générique. Contrairement au schéma, qui doit être en minuscules, la partie hôte ne respecte pas la casse. Selon la façon dont sa partie hôte est spécifiée, un UrlPrefix appartient à l’une des quatre catégories de routage suivantes, qui sont décrites plus en détail ci-dessous :

Caractère générique fort
Explicit (Explicite)
Caractère générique faible lié à l’adresse IP
Caractère générique faible

Port

Chaîne numérique décimale qui ne commence pas par zéro et qui représente un numéro de port TCP valide (1 à 65 535). Cette valeur ne peut pas être un caractère générique.

relativeURI

L’élément relativeURI est facultatif, mais s’il est présent, il doit toujours être suivi d’une barre oblique (« / »). Il s’agit d’une chaîne de préfixe qui indique une sous-arborescence dans l’espace de noms de l’ordinateur spécifié par rapport aux valeurs de schéma, d’hôte et de port. Contrairement au schéma, qui doit être en minuscules, la partie relativeURI ne respecte pas la casse.

Voici des exemples d’UrlPrefixes correctement formés :

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

catégories Host-Specifier

Pour plus de flexibilité et de facilité d’utilisation, l’API serveur HTTP prend en charge quatre façons différentes de spécifier des hôtes. Les quatre catégories de spécificateur d’hôte sont répertoriées ci-dessous par ordre de priorité :

Caractère générique fort (signe Plus)

Lorsque l’élément hôte d’un UrlPrefix se compose d’un seul signe plus (+), urlPrefix correspond à tous les noms d’hôtes possibles dans le contexte de ses éléments de schéma, de port et de relativeURI, et tombe dans la catégorie de caractères génériques forts.

Un caractère générique fort est utile lorsqu’une application doit traiter les demandes adressées à un ou plusieurs relativeURIs, quelle que soit la façon dont ces requêtes arrivent sur l’ordinateur ou le site qu’elles spécifient dans leurs en-têtes d’hôte. L’utilisation d’un caractère générique fort dans cette situation évite d’avoir à spécifier une liste exhaustive d’adresses IP et/ou d’hôtes.

Explicite

Un nom d’hôte explicite tel qu’un nom de domaine complet dans l’élément host place un UrlPrefix dans la catégorie explicite. Ce type d’élément hôte est mis en correspondance directement avec les en-têtes d’hôte des requêtes entrantes.

Les spécifications d’hôte explicites sont utiles pour les applications multisite telles que les serveurs web qui fournissent un contenu différent en fonction du site vers lequel la demande a été dirigée.

Caractère générique faible lié à l’adresse IP

Lorsqu’une adresse IP apparaît en tant qu’élément hôte, urlPrefix se classe dans la catégorie caractère générique faible lié à l’adresse IP. Ce type d’UrlPrefix correspond à n’importe quel nom d’hôte pour l’interface IP spécifiée avec le schéma, le port et la relativeURI spécifiés, et qui n’a pas encore été mis en correspondance par un caractère générique fort ou un UrlPrefix explicite. L’adresse IP prend l’une des deux formes dans l’élément hôte :

Chaîne littérale IPv4

Un littéral IPv4 se compose de quatre nombres décimaux en pointillés, chacun dans la plage 0-255, par exemple 192.168.0.0.

Chaîne littérale IPv6

Une chaîne littérale IPv6 est placée entre crochets et contient des nombres hexadécimaux séparés par des points-virgules ; par exemple : [::1] ou [3ffe:ffff::6ECB:0101].

Les spécificateurs d’hôte à caractère générique faible lié à l’adresse IP sont destinés aux applications qui varient le contenu qu’elles servent en fonction de l’itinéraire emprunté par les requêtes entrantes. Ne vous fiez pas aux spécificateurs d’hôte à caractère générique faible lié à l’adresse IP pour appliquer la sécurité.

Caractère générique faible (astérisque)

Lorsqu’un astérisque (*) s’affiche en tant qu’élément hôte, urlprefix tombe dans la catégorie de caractères génériques faibles. Ce type d’UrlPrefix correspond à n’importe quel nom d’hôte associé au schéma, au port et à la relativeURI spécifiés qui n’a pas encore été mis en correspondance par un url à caractère générique fort, explicite ou à caractère générique faible lié à l’adresse IP.

Cette spécification d’hôte peut être utilisée comme fourre-tout par défaut dans certaines circonstances, ou peut être utilisée pour spécifier une grande section de l’espace de noms d’URL sans avoir à utiliser de nombreux UrlPrefixes.

UrlPréfix Détection des conflits lors de la réservation et de l’inscription

À des fins de réservation et d’inscription, les quatre différentes catégories d’UrlPrefix sont traitées séparément, sans référence les unes aux autres. Il est possible d’inscrire des UrlPrefixes en conflit tant qu’ils se trouvent dans différentes catégories. Ce n’est qu’au sein de la même catégorie qu’un conflit entraîne l’échec d’une tentative de réservation.

Par exemple, il serait possible de réserver à la fois l’UrlPrefix https://www.adatum.com:80/vroot/ explicite et le caractère générique fort en conflit UrlPrefix https://+:80/vroot/, car ils appartiennent à différentes catégories. Toutefois, une tentative ultérieure de réservation https://+:80/vroot/ à un autre utilisateur échouerait, car elle serait en conflit avec une réservation existante dans sa propre catégorie.

Comportement de routage

Lors du routage d’une requête HTTP entrante, l’API de serveur HTTP commence par la catégorie de caractères génériques forts et compare l’URL entrante à la fois inscrite et réservée UrlPrefixes dans cette catégorie.

Si l’URL entrante correspond à une réservation, mais pas à une inscription, l’API serveur HTTP échoue à la demande. Cela empêche les inscriptions de priorité inférieure de pouvoir récupérer des demandes qui ne lui sont pas destinées. Le status en cas d’échec est 400 (« Demande incorrecte ») au lieu de 503 (« Service non disponible »), car un retour 503 est parfois interprété à tort par les passerelles d’équilibrage de charge comme indiquant que le serveur a été surchargé.

Si une inscription correspondante est trouvée dans la catégorie, la demande est acheminée vers la file d’attente de demandes associée à cette inscription. La requête est toujours acheminée vers la file d’attente associée au plus long urlPrefix correspondant d’une catégorie.

Si aucune correspondance n’est trouvée dans la catégorie, l’API serveur HTTP passe à la catégorie explicite et répète la même procédure. Pour résumer, l’ordre dans lequel les catégories sont examinées est le suivant :

  1. Caractère générique fort
  2. Explicit (Explicite)
  3. IP-Bound caractère générique faible
  4. Caractère générique faible

Si aucune correspondance n’est trouvée dans l’une des catégories, l’API serveur HTTP envoie une réponse avec un code status de 400 pour indiquer que la demande ne peut pas être routée.

Règle de correspondance la plus longue

Dans chaque catégorie UrlPrefix, l’API serveur HTTP achemine une requête vers la file d’attente associée à la correspondance UrlPrefix la plus longue. Par exemple, supposons que les deux UrlPrefixes suivants sont inscrits dans différentes files d’attente :

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

L’API serveur HTTP achemine une requête pour https://www.adatum.com:80/default.htm vers File d’attente1 et une requête pour https://www.adatum.com:80/dir/sna/snadefault.htm vers Queue2. Il achemine une requête pour https://www.adatum.com:80/dir/app.htm vers File d’attente1, car la correspondance complète la plus longue est avec UrlPrefix https://www.adatum.com:80/ , et non avec UrlPrefix https://www.adatum.com:80/dir/sna .