Delen via

UrlPrefix-tekenreeksen

  • Artikel

In de HTTP Server-API is een UrlPrefix- een Unicode-tekenreeks (UTF-16) met een canonieke vorm waarmee een sectie van de URL-naamruimte wordt opgegeven. Deze wordt gebruikt om een sectie van de URL-naamruimte te reserveren voor een gebruikersaccount of om een sectie van de URL-naamruimte voor een proces te registreren.

UrlPrefix-indeling

Een UrlPrefix heeft de volgende syntaxis:

"scheme://host:port/relativeURI"

Het schema, de host- en poortelementen van een UrlPrefix moeten aanwezig en niet leeg zijn en moeten voldoen aan de volgende regels:

schema

Moet http of https zijn, allemaal in kleine letters.

host

Moet een volledig gekwalificeerde domeinnaam, een letterlijke IPv4- of IPv6-tekenreeks of een jokerteken zijn. In tegenstelling tot het schema, dat kleine letters moet zijn, is het hostgedeelte niet hoofdlettergevoelig. Afhankelijk van de wijze waarop het hostgedeelte is opgegeven, valt een UrlPrefix in een van de volgende vier routeringscategorieën, die in meer detail hieronder worden beschreven:

Sterk jokerteken
Uitdrukkelijk
IP-gebonden zwakke jokerteken
Zwak jokerteken

poort

Een decimale numerieke tekenreeks die niet begint met nul en die een geldig TCP-poortnummer vertegenwoordigt (1 tot 65.535). Deze waarde kan geen jokerteken zijn.

relatieve URI

Het relatieveURI-element is optioneel, maar als aanwezig altijd moet worden gevolgd door een slash (/). Dit is een voorvoegseltekenreeks die een substructuur aangeeft binnen de naamruimte van de machine die is opgegeven ten opzichte van het schema, de host- en poortwaarden. In tegenstelling tot het schema, dat kleine letters moet zijn, is het relatieveURI-gedeelte niet hoofdlettergevoelig.

Voorbeelden van correct gevormde UrlPrefixes zijn:

  • https://www.adatum.com:80/vroot/
  • https://adatum.com:443/secure/database/
  • https://+:80/vroot/

Host-Specifier categorieën

Voor flexibiliteit en gebruiksgemak ondersteunt de HTTP Server-API vier verschillende manieren om hosts op te geven. De vier categorieën voor hostaanduidingen worden hieronder vermeld in volgorde van prioriteit:

Sterk jokerteken (plusteken)

Wanneer het hostelement van een UrlPrefix bestaat uit één plusteken (+), komt de UrlPrefix overeen met alle mogelijke hostnamen in de context van de schema-, poort- en relatieveURI-elementen en valt deze in de categorie met sterke jokertekens.

Een sterk jokerteken is handig wanneer een toepassing aanvragen moet verwerken die zijn geadresseerd aan een of meer relatieve URI's, ongeacht hoe deze aanvragen op de computer aankomen of welke site ze opgeven in hun Host-headers. Het gebruik van een sterk jokerteken in deze situatie voorkomt dat een volledige lijst met host- en/of IP-adressen moet worden opgegeven.

expliciete

Een expliciete hostnaam, zoals een volledig gekwalificeerde domeinnaam in het hostelement, plaatst een UrlPrefix in de expliciete categorie. Dit type hostelement wordt rechtstreeks vergeleken met de hostheaders van binnenkomende aanvragen.

Expliciete hostspecificaties zijn handig voor toepassingen met meerdere sites, zoals webservers die verschillende inhoud leveren, afhankelijk van de site waarop de aanvraag is gericht.

IP-gebonden zwakke jokerteken

Wanneer een IP-adres wordt weergegeven als het hostelement, valt de UrlPrefix in de categorie Zwak jokerteken met IP-gebonden. Dit type UrlPrefix komt overeen met een hostnaam voor de opgegeven IP-interface met het opgegeven schema, de poort en de relatieveURI, en die nog niet is vergeleken met een sterk-jokerteken of expliciet UrlPrefix. Het IP-adres heeft een van de twee vormen in het hostelement:

letterlijke IPv4-tekenreeks

Een letterlijke IPv4-waarde bestaat uit vier gestippelde decimale getallen, elk in het bereik van 0-255, zoals 192.168.0.0.

letterlijke IPv6-tekenreeks

Een letterlijke IPv6-tekenreeks staat tussen vierkante haken en bevat hexnummers gescheiden door dubbele punten; bijvoorbeeld: [::1] of [3ffe:ffff::6ECB:0101].

IP-gebonden zwakke-jokertekenhostaanduidingen zijn bedoeld voor toepassingen die de inhoud variëren die ze leveren op basis van de route die wordt genomen door binnenkomende aanvragen. Vertrouw niet op IP-gebonden hostaanduidingen met zwakke jokertekens om beveiliging af te dwingen.

Zwak jokerteken (sterretje)

Wanneer een sterretje (*) wordt weergegeven als het hostelement, valt de UrlPrefix in de zwakke categorie jokertekens. Dit type UrlPrefix komt overeen met een hostnaam die is gekoppeld aan het opgegeven schema, de poort en de relatieveURI die nog niet is vergeleken met een sterk jokerteken, expliciet of IP-gebonden zwak-jokerteken UrlPrefix.

Deze hostspecificatie kan in sommige gevallen worden gebruikt als standaard catch-all, of kan worden gebruikt om een grote sectie van url-naamruimte op te geven zonder veel UrlPrefixes te hoeven gebruiken.

UrlPrefix-conflictdetectie tijdens reservering en registratie

Voor reserverings- en registratiedoeleinden worden de vier verschillende categorieën UrlPrefix afzonderlijk behandeld, zonder te verwijzen naar elkaar. Het is mogelijk om conflicterende UrlPrefixes te registreren zolang ze zich in verschillende categorieën bevinden. Alleen binnen dezelfde categorie is er een conflict waardoor een reserveringspoging mislukt.

Het is bijvoorbeeld mogelijk om zowel het expliciete UrlPrefix-https://www.adatum.com:80/vroot/ als het conflicterende sterke URLPrefix https://+:80/vroot/te reserveren, omdat ze tot verschillende categorieën behoren. Een volgende poging om https://+:80/vroot/ aan een andere gebruiker te reserveren, mislukt echter omdat deze een conflict veroorzaakt met een bestaande reservering in een eigen categorie.

Routeringsgedrag

Bij het routeren van een binnenkomende HTTP-aanvraag begint de HTTP Server-API met de sterke categorie jokertekens en vergelijkt de binnenkomende URL met zowel geregistreerde als gereserveerde UrlPrefixes in die categorie.

Als de binnenkomende URL overeenkomt met een reservering maar geen registratie, mislukt de HTTP Server-API de aanvraag. Hiermee voorkomt u dat registraties met een lagere prioriteit aanvragen kunnen ophalen die niet zijn bedoeld voor deze registraties. De status bij een fout is 400 ('Ongeldige aanvraag') in plaats van 503 ('Service niet beschikbaar'),, omdat een retour van 503 soms per ongeluk wordt geïnterpreteerd door taakverdelingsgateways die aangeven dat de server overbelast is.

Als er een overeenkomende registratie in de categorie wordt gevonden, wordt de aanvraag doorgestuurd naar de aanvraagwachtrij die aan die registratie is gekoppeld. De aanvraag wordt altijd doorgestuurd naar de wachtrij die is gekoppeld aan het langste overeenkomende UrlPrefix binnen een categorie.

Als er geen overeenkomst wordt gevonden in de categorie, gaat de HTTP Server-API naar de expliciete categorie en herhaalt u dezelfde procedure. Samenvattend is de volgorde waarin de categorieën worden onderzocht als volgt:

  1. Sterk jokerteken
  2. Uitdrukkelijk
  3. IP-Bound zwak jokerteken
  4. Zwak jokerteken

Als er geen overeenkomst wordt gevonden in een van de categorieën, verzendt de HTTP Server-API een antwoord met de statuscode 400 om aan te geven dat de aanvraag niet kan worden gerouteerd.

Langste overeenkomstregel

Binnen elke categorie UrlPrefix stuurt DE HTTP Server-API een aanvraag naar de wachtrij die is gekoppeld aan het langst overeenkomende UrlPrefix. Stel dat de volgende twee UrlPrefixes zijn geregistreerd bij verschillende wachtrijen:

  • Queue1 https://www.adatum.com:80/
  • Queue2 https://www.adatum.com:80/dir/sna/

De HTTP Server-API stuurt een aanvraag voor https://www.adatum.com:80/default.htm naar Queue1 en een aanvraag voor https://www.adatum.com:80/dir/sna/snadefault.htm naar Queue2. Er wordt een aanvraag voor https://www.adatum.com:80/dir/app.htm naar Queue1 gerouteerd omdat de langste volledige overeenkomst overeenkomt met de https://www.adatum.com:80/ UrlPrefix, niet met de https://www.adatum.com:80/dir/sna UrlPrefix.