Freigeben über

UrlPrefix Strings (UrlPrefix-Zeichenfolgen)

  • Artikel

In der HTTP-Server-API ist ein UrlPrefix eine UTF-16-Unicode-Zeichenfolge (Wide-Character) mit einer kanonischen Form, die einen Abschnitt des URL-Namespace angibt. Es wird verwendet, um einen Abschnitt des URL-Namespace für ein Benutzerkonto zu reservieren oder einen Abschnitt des URL-Namespace für einen Prozess zu registrieren.

UrlPrefix-Format

Ein UrlPrefix weist die folgende Syntax auf:

"scheme://host:port/relativeURI"

Das Schema, der Host und die Portelemente eines UrlPrefix müssen vorhanden und nicht leer sein und den folgenden Regeln entsprechen:

Schema

Muss entweder http oder https sein, alles in Kleinbuchstaben.

Host

Muss ein vollqualifizierter Domänenname, eine IPv4- oder IPv6-Literalzeichenfolge oder ein Wildcard sein. Im Gegensatz zum Schema, das kleingeschrieben sein muss, wird beim Hostteil die Groß-/Kleinschreibung nicht beachtet. Je nachdem, wie der Hostteil angegeben wird, fällt ein UrlPrefix in eine der folgenden vier Routingkategorien, die unten ausführlicher beschrieben werden:

Starker Wildcard
Explizit
IP-gebundener schwacher Wildcard
Schwaches Wildcard

Hafen

Eine dezimale numerische Zeichenfolge, die nicht mit 0 beginnt und eine gültige TCP-Portnummer (1 bis 65.535) darstellt. Dieser Wert darf kein Wildcard sein.

Relativeuri

Das relativeURI-Element ist optional, aber wenn vorhanden, muss immer ein Schrägstrich ("/") folgen. Dies ist eine Präfixzeichenfolge, die eine Unterstruktur innerhalb des Namespace des Computers angibt, der relativ zu den Schema-, Host- und Portwerten angegeben ist. Im Gegensatz zum Schema, das klein geschrieben werden muss, wird für den relativen URI-Teil die Groß-/Kleinschreibung nicht beachtet.

Beispiele für ordnungsgemäß formatierte UrlPrefixes sind:

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

Host-Specifier Kategorien

Aus Gründen der Flexibilität und Benutzerfreundlichkeit unterstützt die HTTP-Server-API vier verschiedene Möglichkeiten zum Angeben von Hosts. Die vier Hostspezifiziererkategorien sind unten in rangfolgerischer Reihenfolge aufgeführt:

Starker Wildcard (Pluszeichen)

Wenn das Hostelement eines UrlPrefix aus einem einzelnen Pluszeichen (+) besteht, stimmt urlPrefix mit allen möglichen Hostnamen im Kontext seiner Schema-, Port- und relativURI-Elemente überein und fällt in die starke Wildcard-Kategorie.

Ein starker Platzhalter ist nützlich, wenn eine Anwendung Anforderungen an eine oder mehrere relativeURIs bereitstellen muss, unabhängig davon, wie diese Anforderungen auf dem Computer eingehen oder welchen Standort sie in ihren Hostheadern angeben. Die Verwendung eines starken Wildcards in dieser Situation vermeidet die Notwendigkeit, eine vollständige Liste von Host- und/oder IP-Adressen anzugeben.

Explizit

Ein expliziter Hostname, z. B. ein vollqualifizierter Domänenname im Hostelement, platziert ein UrlPrefix in der expliziten Kategorie. Diese Art von Hostelement wird direkt mit den Hostheadern eingehender Anforderungen abgeglichen.

Explizite Hostspezifikationen sind nützlich für Anwendungen mit mehreren Standorten, z. B. Webserver, die je nach Standort, an den die Anforderung gerichtet wurde, unterschiedliche Inhalte bereitstellen.

IP-gebundener schwacher Wildcard

Wenn eine IP-Adresse als Hostelement angezeigt wird, fällt urlPrefix in die IP-gebundene Kategorie Weak Wildcard. Diese Art von UrlPrefix gleicht jeden Hostnamen für die angegebene IP-Schnittstelle mit dem angegebenen Schema, port und relativeURI ab und wurde noch nicht durch ein Strong-Wildcard oder explizites UrlPrefix abgeglichen. Die IP-Adresse hat eine von zwei Formen im Hostelement:

IPv4-Literalzeichenfolge

Ein IPv4-Literal besteht aus vier gepunkteten Dezimalzahlen, die jeweils im Bereich von 0 bis 255 liegen, z. B. 192.168.0.0.

IPv6-Literalzeichenfolge

Eine IPv6-Literalzeichenfolge ist in eckige Klammern eingeschlossen und enthält durch Doppelpunkte getrennte Hexadezimalzahlen. Beispiel: [::1] oder [3ffe:ffff::6ECB:0101].

IP-gebundene Schwache-Wildcard-Hostspezifizierer sind für Anwendungen vorgesehen, die den Inhalt, den sie bereitstellen, basierend auf der Route der eingehenden Anforderungen variieren. Verlassen Sie sich nicht auf IP-gebundene Schwache-Wildcard-Hostspezifizierer, um Sicherheit zu erzwingen.

Schwacher Platzhalter (Sternchen)

Wenn ein Sternchen (*) als Hostelement angezeigt wird, fällt urlPrefix in die schwache Platzhalterkategorie. Diese Art von UrlPrefix stimmt mit jedem Hostnamen überein, der dem angegebenen Schema, Port und relativeURI zugeordnet ist, der noch nicht mit einem starken Wildcard, expliziten oder IP-gebundenen schwachen Wildcard-UrlPrefix abgeglichen wurde.

Diese Hostspezifikation kann unter bestimmten Umständen als Standard-Catch-All verwendet oder verwendet werden, um einen großen Abschnitt des URL-Namespace anzugeben, ohne viele UrlPrefixes verwenden zu müssen.

UrlPrefix-Konflikterkennung während der Reservierung und Registrierung

Zu Reservierungs- und Registrierungszwecken werden die vier verschiedenen Kategorien von UrlPrefix getrennt behandelt, ohne aufeinander bezugslos. Es ist möglich, in Konflikt stehende UrlPrefixes zu registrieren, solange sie sich in verschiedenen Kategorien befinden. Nur innerhalb derselben Kategorie führt ein Konflikt dazu, dass ein Reservierungsversuch fehlschlägt.

Beispielsweise wäre es möglich, sowohl das explizite UrlPrefix https://www.adatum.com:80/vroot/ als auch den in Konflikt stehenden starken Wildcard UrlPrefix https://+:80/vroot/zu reservieren, da sie zu verschiedenen Kategorien gehören. Ein nachfolgender Versuch, einen anderen Benutzer zu reservieren https://+:80/vroot/ , würde jedoch fehlschlagen, da er mit einer vorhandenen Reservierung in seiner eigenen Kategorie in Konflikt stand.

Routingverhalten

Beim Weiterleiten einer eingehenden HTTP-Anforderung beginnt die HTTP-Server-API mit der starken Wildcardkategorie und vergleicht die eingehende URL mit registrierten und reservierten UrlPrefixes in dieser Kategorie.

Wenn die eingehende URL mit einer Reservierung, aber nicht mit einer Registrierung übereinstimmt, schlägt die HTTP-Server-API die Anforderung fehl. Dadurch wird verhindert, dass Registrierungen mit niedrigerer Priorität Anforderungen aufnehmen können, die nicht für sie vorgesehen sind. Der status bei Einem Fehler ist 400 ("Ungültige Anforderung") und nicht 503 ("Dienst nicht verfügbar"), da eine 503-Rückgabe von Lastenausgleichsgateways manchmal fälschlicherweise als Hinweis darauf interpretiert wird, dass der Server überlastet war.

Wenn eine übereinstimmende Registrierung innerhalb der Kategorie gefunden wird, wird die Anforderung an die Anforderungswarteschlange weitergeleitet, die dieser Registrierung zugeordnet ist. Die Anforderung wird immer an die Warteschlange weitergeleitet, die dem längsten übereinstimmenden UrlPrefix innerhalb einer Kategorie zugeordnet ist.

Wenn keine Übereinstimmung in der Kategorie gefunden wird, fährt die HTTP-Server-API mit der expliziten Kategorie fort und wiederholt dieselbe Prozedur. Zusammenfassend lautet die Reihenfolge, in der die Kategorien untersucht werden, wie folgt:

  1. Starker Wildcard
  2. Explizit
  3. IP-Bound schwachen Wildcard
  4. Schwaches Wildcard

Wenn keine Übereinstimmung in einer der Kategorien gefunden wird, sendet die HTTP-Server-API eine Antwort mit dem status Code 400, um anzugeben, dass die Anforderung nicht weitergeleitet werden kann.

Längste Übereinstimmungsregel

Innerhalb jeder UrlPrefix-Kategorie leitet die HTTP-Server-API eine Anforderung an die Warteschlange weiter, die dem längsten übereinstimmenden UrlPrefix zugeordnet ist. Angenommen, die folgenden beiden UrlPrefixes sind in unterschiedlichen Warteschlangen registriert:

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

Die HTTP-Server-API leitet eine Anforderung für https://www.adatum.com:80/default.htm an Queue1 und eine Anforderung für https://www.adatum.com:80/dir/sna/snadefault.htm an Queue2 weiter. Eine Anforderung für https://www.adatum.com:80/dir/app.htm wird an Queue1 weitergeleitet, da die längste vollständige Übereinstimmung mit urlPrefix https://www.adatum.com:80/ und nicht mit https://www.adatum.com:80/dir/sna UrlPrefix besteht.