Delen via

Binnenkomende aanvragen routeren

  • Artikel

De HTTP Server-API onderhoudt een routeringsdatabase om te bepalen welke toepassing een binnenkomende aanvraag ontvangt. De routeringstabel is opgebouwd uit de reserveringsdatabase en bevat reserveringsvermeldingen en huidige registraties. Wanneer een registratie of reservering wordt gemaakt, wordt deze als volgt in de bucket voor de routeringsdatabase geplaatst die overeenkomt met het hosttype:

  • + : poortregistraties worden in de bucket 'Sterk jokerteken' geplaatst

  • host: poortregistraties worden in de bucket Expliciet geplaatst

  • IP: poortregistraties worden in de bucket IP-gebonden zwakke jokerteken geplaatst

  • * : poortregistraties worden in de bucket Zwak jokerteken geplaatst

Deze stappen verwijzen ook naar de volgorde waarin binnenkomende HTTP-aanvragen worden verwerkt. Eerst worden de sterke jokertekenreserveringen gecontroleerd, gevolgd door het IP-gebonden zwakke jokerteken en zwakke jokerteken. De zoekopdracht stopt wanneer er een overeenkomst wordt gevonden, zodat registraties in een van de resterende buckets niet worden gevonden.

Het HTTP Server API-routeringsalgoritmen zoeken de beste overeenkomst voor de UrlPrefix door zowel de registratievermeldingen als de reserveringsvermeldingen van de routeringsdatabase te doorzoeken, te beginnen met de sterke jokertekenbucket en eindigend met de zwakke bucket met jokertekens. De beste overeenkomst, binnen een bucket, is de langste overeenkomst in het relatieve URI-gedeelte van urlPrefix (ervan uitgaande dat een exacte overeenkomst is voor de host-, poort- en schemagedeelten van de URL). Nadat een overeenkomst in een bucket is gevonden, stopt het routeringsalgoritme de zoekopdracht en worden alle buckets met lagere prioriteit overgeslagen.

Denk bijvoorbeeld aan de volgende registraties (vermeld in aflopende volgorde van prioriteit op basis van buckettypen:

  • Registratie: https://+:80/vroot/ is geregistreerd door toepassing 1

  • Registratie: https://adatum.com:80/ wordt geregistreerd door toepassing 2

  • Registratie: https://\*:80/ wordt geregistreerd door toepassing 3

Een binnenkomende aanvraag voor https://adatum.com:80/vroot/subdir/file.htm/ wordt bezorgd bij toepassing 1. Er wordt een binnenkomende aanvraag voor https://adatum.com:80/default.htm/ aan toepassing 2 geleverd. Er wordt een binnenkomende aanvraag voor https://otheradatum.com:80/file.htm/ bezorgd bij toepassing 3.

Als de beste overeenkomst een reserveringsvermelding is, betekent dit dat de toepassing die de aanvraag moet ontvangen, niet wordt uitgevoerd. Denk bijvoorbeeld aan de volgende registratie en reservering:

  • Registratie: https://\*:80/vroot/ is geregistreerd door toepassing 1, gebruiker A

  • Reservering: https://adatum.com:80/ is gereserveerd voor gebruiker B

Een binnenkomende aanvraag voor https://adatum.com:80/vroot/file.htm/ wordt niet bezorgd bij toepassing 1 omdat de beste overeenkomst leidt tot de reserveringsvermelding voor gebruiker B. De prioriteitsregels worden in dit geval toegepast op de reservering met een hogere prioriteit. Als er geen proces actief is dat is geautoriseerd en geregistreerd bij serviceaanvragen voor de ontvangen URL, wordt de aanvraag geweigerd met een 400-statuscode (Ongeldige aanvraag).