Routage des demandes entrantes

L’API serveur HTTP gère une base de données de routage pour déterminer l’application qui 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 des entrées de réservation ainsi que des 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 ports 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é à 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 des requêtes HTTP entrantes traitées. Les réservations à caractères génériques forts commencent par vérifier la réservation explicite, suivie 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 afin que les inscriptions dans l’un des compartiments restants ne soient pas trouvées.

L’algorithme de routage de l’API du serveur HTTP recherche la meilleure correspondance pour le URLPrefix en recherchant 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 générique fort et en se 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 l’hôte, le port et les parties de 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 inscrit par l’application 1

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

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

Une demande entrante de https://adatum.com:80/vroot/subdir/file.htm/ est remise à l’application 1. Une demande entrante de 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, tenez compte de l’inscription et de la réservation suivantes :

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

• Réservation : https://adatum.com:80/ a été réservé à 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 mène à 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 n’est actif qui est autorisé et inscrit aux demandes de service pour l’URL reçue, la demande est rejetée avec un code d’état 400 (demande incorrecte).