Partager via

Routage des demandes entrantes

  • Article

L’API serveur HTTP gère une base de données de routage pour déterminer quelle application reçoit une requête entrante. La table de routage est générée à partir de la base de données de réservation et contient les entrées de réservation ainsi que les inscriptions actuelles. Lorsqu’une inscription ou une réservation est effectuée, elle est placée dans le compartiment de base de données de routage qui correspond au type d’hôte comme suit :

  • + : les inscriptions de port sont placées dans le compartiment « Caractère générique fort »

  • hôte : les inscriptions de port sont placées dans le compartiment « Explicite »

  • IP : les inscriptions de port sont placées dans le compartiment « Caractère générique faible lié à l’adresse IP »

  • * : les inscriptions de port sont placées dans le compartiment « Caractère générique faible »

Ces étapes font également référence à l’ordre dans lequel les requêtes HTTP entrantes sont traitées. Les réservations de caractères génériques forts sont d’abord vérifiées, puis les réservations explicites sont vérifiées, suivies du caractère générique faible lié à l’adresse IP et du caractère générique faible. La recherche s’arrête lorsqu’une correspondance est trouvée, de sorte que les inscriptions dans les compartiments restants ne sont pas trouvées.

L’algorithme de routage de l’API serveur HTTP recherche la meilleure correspondance pour UrlPrefix en recherchant à la fois les entrées d’inscription et les entrées de réservation de la base de données de routage, en commençant par le compartiment de caractères génériques fort et en terminant par le compartiment générique faible. La meilleure correspondance, dans un compartiment, est la correspondance la plus longue dans la partie URI relative de l’URLPrefix (en supposant une correspondance exacte pour les parties hôte, port et schéma de l’URL). Une fois qu’une correspondance est trouvée dans un compartiment, l’algorithme de routage arrête sa recherche et ignore tous les compartiments de priorité inférieure.

Par exemple, considérez les inscriptions suivantes (répertoriées dans l’ordre décroissant de priorité en fonction des types de compartiments :

  • Inscription : https://+:80/vroot/ est inscrite par l’application 1

  • Inscription : https://adatum.com:80/ est inscrite par l’application 2

  • Inscription : https://\*:80/ est inscrite par l’application 3

Une demande entrante pour https://adatum.com:80/vroot/subdir/file.htm/ est remise à l’application 1. Une demande entrante pour https://adatum.com:80/default.htm/ est remise à l’application 2. Une demande entrante pour https://otheradatum.com:80/file.htm/ est remise à l’application 3.

Si la meilleure correspondance est une entrée de réservation, cela signifie que l’application qui doit recevoir la demande n’est pas en cours d’exécution. Par exemple, considérez l’inscription et la réservation suivantes :

  • Inscription : https://\*:80/vroot/ est inscrit par l’application 1, utilisateur A

  • Réservation : https://adatum.com:80/ a été réservée à l’utilisateur B

Une demande entrante pour https://adatum.com:80/vroot/file.htm/ n’est pas remise à l’application 1, car la meilleure correspondance conduit à l’entrée de réservation pour l’utilisateur B. Les règles de précédence sont appliquées dans ce cas à la réservation qui a une priorité plus élevée. Si aucun processus actif n’est autorisé et inscrit pour traiter les demandes pour l’URL reçue, la demande est rejetée avec un code de 400 status (requête incorrecte).