Freigeben über

UrlPrefix-Zeichenfolgen

  • Artikel

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

UrlPrefix-Format

Ein UrlPrefix weist die folgende Syntax auf:

"scheme://host:port/relativeURI"

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

-Schema

Muss "http" oder "https" in Kleinbuchstaben sein.

host

Muss ein vollqualifizierter Domänenname, eine IPv4- oder IPv6-Literalzeichenfolge oder ein Wildcard sein. Im Gegensatz zum Schema, das Kleinbuchstaben sein muss, wird die Groß-/Kleinschreibung des Hostteils 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:

Starke Wildcard
Explizit
IP-gebundene schwache Wildcard
Schwache Wildcard

Port

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

relative URI

Das relativeURI-Element ist optional, aber wenn vorhanden, muss immer ein Schrägstrich ("/") gefolgt werden. Dies ist eine Präfixzeichenfolge, die eine Unterstruktur im Namespace des Computers angibt, die relativ zu dem Schema, den Host- und Portwerten angegeben ist. Im Gegensatz zum Schema, das Kleinbuchstaben sein muss, wird bei dem relativen URI-Teil die Groß-/Kleinschreibung nicht beachtet.

Beispiele für richtig gebildete UrlPrefixes sind:

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

Host-Specifier Kategorien

Um Flexibilität und Benutzerfreundlichkeit zu gewährleisten, unterstützt die HTTP-Server-API vier verschiedene Möglichkeiten zum Angeben von Hosts. Die vier Kategorien des Hostbezeichners sind unten aufgeführt, um Vorrang zu haben:

Starke Wildcard (Pluszeichen)

Wenn das Hostelement eines UrlPrefix-Elements aus einem einzelnen Pluszeichen (+) besteht, gleicht die UrlPrefix alle möglichen Hostnamen im Kontext des Schemas, der Port- und relativURI-Elemente ab und fällt in die starke Wildcardkategorie.

Eine starke Wildcard ist nützlich, wenn eine Anwendung Anforderungen an eine oder mehrere relativeURIs adressieren muss, unabhängig davon, wie diese Anforderungen auf dem Computer eingehen oder welche Website 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 eine UrlPrefix in der expliziten Kategorie. Diese Art von Hostelement wird direkt mit den Hostheadern eingehender Anforderungen abgeglichen.

Explizite Hostspezifikationen sind für Anwendungen mit mehreren Standorten nützlich, z. B. Webserver, die je nach Website, an die die Anforderung weitergeleitet wurde, unterschiedliche Inhalte liefern.

IP-gebundenen schwachen Wildcards

Wenn eine IP-Adresse als Hostelement angezeigt wird, fällt die UrlPrefix in die IP-gebundene Kategorie "Schwache Wildcard". Diese Art von UrlPrefix stimmt mit jedem Hostnamen für die angegebene IP-Schnittstelle mit dem angegebenen Schema, Port und relativeURI überein, und das noch nicht mit einem starken Wildcard oder expliziten UrlPrefix abgeglichen wurde. Die IP-Adresse akzeptiert eine von zwei Formen im Hostelement:

IPv4-Literalzeichenfolge

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

IPv6-Literalzeichenfolge

Eine IPv6-Literalzeichenfolge ist in eckige Klammern eingeschlossen und enthält Hexadexnummern, die durch Doppelpunkte getrennt sind; Beispiel: [::1] oder [3ffe:ffff::6ECB:0101].

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

Schwacher Wildcard (Sternchen)

Wenn ein Sternchen (*) als Hostelement angezeigt wird, fällt die UrlPrefix in die schwache Platzhalterkategorie. Diese Art von UrlPrefix entspricht jedem Hostnamen, der dem angegebenen Schema, portieren und relativen URI zugeordnet ist, die noch nicht mit einem starken, expliziten oder IP-gebundenen Schwach-Wildcard-UrlPrefix abgeglichen wurden.

Diese Hostspezifikation kann unter bestimmten Umständen als Standard-Catch-All verwendet werden 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

Für Reservierungs- und Registrierungszwecke werden die vier verschiedenen Kategorien von UrlPrefix separat behandelt, ohne dass auf sie verwiesen wird. Es ist möglich, in Konflikt stehenden UrlPrefixes zu registrieren, solange sie sich in verschiedenen Kategorien befinden. Nur innerhalb derselben Kategorie führt ein Konflikt dazu, dass ein Reservierungsversuch fehlschlägt.

So wäre es beispielsweise möglich, sowohl die explizite urlPrefix-https://www.adatum.com:80/vroot/ als auch die widersprüchliche starke Wildcard-UrlPrefix-https://+:80/vroot/zu reservieren, da sie zu verschiedenen Kategorien gehören. Ein späterer Versuch, https://+:80/vroot/ einem anderen Benutzer zu reservieren, würde jedoch fehlschlagen, da er mit einer vorhandenen Reservierung in seiner eigenen Kategorie in Konflikt stand.

Routingverhalten

Beim Routing 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 abrufen können, die nicht dafür vorgesehen sind. Der Status für fehler ist 400 ("Ungültige Anforderung") und nicht 503 ("Dienst nicht verfügbar"), da eine Rückgabe von 503 manchmal versehentlich von Lastenausgleichsgateways interpretiert wird, wie es angibt, dass der Server überlastet wurde.

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. Zusammengefasst ist die Reihenfolge, in der die Kategorien untersucht werden, wie folgt:

  1. Starke Wildcard
  2. Explizit
  3. IP-Bound schwachen Wildcards
  4. Schwache Wildcard

Wenn keine Übereinstimmung in einer der Kategorien gefunden wird, sendet die HTTP-Server-API eine Antwort mit einem Statuscode von 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 werden in verschiedenen 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. Sie leitet eine Anforderung für https://www.adatum.com:80/dir/app.htm an "Queue1" weiter, da die längste vollständige Übereinstimmung mit dem https://www.adatum.com:80/ UrlPrefix und nicht mit dem https://www.adatum.com:80/dir/sna UrlPrefix besteht.