Freigeben über

Weiterleiten eingehender Anforderungen

  • Artikel

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 vorgenommen wird, wird sie wie folgt in den Routingdatenbank-Bucket platziert, der dem Hosttyp entspricht:

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

  • host : Portregistrierungen werden im Bucket "Explicit" platziert

  • IP: Portregistrierungen werden im Bucket "IP-gebundener schwacher Platzhalter" platziert.

  • * : Portregistrierungen werden im Bucket "Schwacher Platzhalter" platziert.

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

Der HTTP-Server-API-Routingalgorithmus sucht die beste Übereinstimmung für urlPrefix , indem er sowohl die Registrierungseinträge als auch die Reservierungseinträge der Routingdatenbank durchsucht, beginnend mit dem starken Feldhalter-Bucket bis hin zum schwachen Wildcard-Bucket. Die beste Übereinstimmung innerhalb eines Buckets ist die längste Übereinstimmung im relativen URI-Teil von UrlPrefix (unter der Annahme einer exakten Übereinstimmung für die Host-, Port- und Schemateile 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 (aufgeführt in absteigender Reihenfolge der Priorität basierend auf Buckettypen):

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

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

  • Registrierung: https://\*:80/ wird durch 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 empfangen soll, nicht ausgeführt wird. Betrachten Sie beispielsweise die folgende Registrierung und Reservierung:

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

  • 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 Code von 400 status (Ungültige Anforderung) abgelehnt.