Weiterleiten eingehender Anforderungen

Die HTTP-Server-API verwaltet eine Routingdatenbank, um zu bestimmen, welche Anwendung eine eingehende Anforderung empfängt. Die Routingtabelle wird aus der Reservierungsdatenbank erstellt und enthält Reservierungseinträge sowie aktuelle Registrierungen. Wenn eine Registrierung oder Reservierung erfolgt, wird sie im Routingdatenbank-Bucket platziert, der dem Hosttyp wie folgt entspricht:

• + : Portregistrierungen werden im Bucket "Strong Wildcard" platziert

• host: Portregistrierungen werden im Bucket "Explicit" platziert.

• IP: Portregistrierungen werden im Bucket "IP-gebundene schwache Platzhalter" platziert.

• * : Portregistrierungen werden im Bucket "Weak Wildcard" platziert

Diese Schritte beziehen sich auch auf die Reihenfolge, in der eingehende HTTP-Anforderungen verarbeitet werden. Die starken Platzhalterreservierungen zuerst, dann werden die expliziten Reservierungen überprüft, gefolgt von der IP-gebundenen schwachen Platzhalter und schwachen Platzhalter. Die Suche wird beendet, wenn eine Übereinstimmung gefunden wird, sodass Registrierungen in einem der verbleibenden Buckets nicht gefunden werden.

Der HTTP Server-API-Routingalgorithmus findet die beste Übereinstimmung für die UrlPrefix-, indem sowohl die Registrierungseinträge als auch die Reservierungseinträge der Routingdatenbank durchsucht werden, beginnend mit dem starken Wildcard-Bucket und endet mit dem schwachen Wildcard-Bucket. Die beste Übereinstimmung innerhalb eines Buckets ist die längste Übereinstimmung im relativen URI-Teil der UrlPrefix (vorausgesetzt, eine genaue Übereinstimmung für den Host-, Port- und Schemateil der URL). Nachdem eine Übereinstimmung in einem Bucket gefunden wurde, beendet der Routingalgorithmus seine Suche und überspringt alle Buckets mit niedrigerer Priorität.

Betrachten Sie beispielsweise die folgenden Registrierungen (basierend auf Buckettypen in absteigender Reihenfolge der Priorität aufgeführt):

• Registrierung: https://+:80/vroot/ wird von Anwendung 1 registriert.

• Registrierung: https://adatum.com:80/ wird von Anwendung 2 registriert.

• Registrierung: https://\*:80/ wird von Anwendung 3 registriert.

Eine eingehende Anforderung für https://adatum.com:80/vroot/subdir/file.htm/ wird an Anwendung 1 übermittelt. Eine eingehende Anforderung für https://adatum.com:80/default.htm/ wird an Anwendung 2 übermittelt. Eine eingehende Anforderung für https://otheradatum.com:80/file.htm/ wird an Anwendung 3 übermittelt.

Wenn die beste Übereinstimmung ein Reservierungseintrag ist, bedeutet dies, dass die Anwendung, die die Anforderung erhalten soll, nicht ausgeführt wird. Betrachten Sie z. B. die folgende Registrierung und Reservierung:

• Registrierung: https://\*:80/vroot/ wird von Anwendung 1, Benutzer A registriert.

• Reservierung: https://adatum.com:80/ wurde für Benutzer B reserviert.

Eine eingehende Anforderung für https://adatum.com:80/vroot/file.htm/ wird nicht an Anwendung 1 übermittelt, da die beste Übereinstimmung zum Reservierungseintrag für Benutzer B führt. Die Rangfolgeregeln werden in diesem Fall auf die Reservierung angewendet, die eine höhere Priorität hat. Wenn kein Prozess aktiv ist, der für Dienstanforderungen für die empfangene URL autorisiert und registriert ist, wird die Anforderung mit einem Statuscode von 400 (Ungültige Anforderung) abgelehnt.