UrlPrefix Strings (UrlPrefix 文字列)

[アーティクル]
06/12/2023

HTTP Server API では、 UrlPrefix は、URL 名前空間のセクションを指定する正規形式のワイド文字 (UTF-16) Unicode 文字列です。これは、ユーザーアカウントの URL 名前空間のセクションを予約したり、プロセスの URL 名前空間のセクションを登録したりするために使用されます。

UrlPrefix 形式

UrlPrefix には、次の構文があります。

"scheme://host:port/relativeURI"

UrlPrefix のスキーム、ホスト、およびポートの要素は存在し、空でない必要があり、次の規則に従う必要があります。

スキーム

すべて小文字の http または https である必要があります。

ホスト

完全修飾ドメイン名、IPv4 または IPv6 リテラル文字列、またはワイルドカードである必要があります。小文字にする必要があるスキームとは異なり、ホスト部分では大文字と小文字が区別されません。ホスト部分の指定方法に応じて、UrlPrefix は次の 4 つのルーティングカテゴリのいずれかに分類されます。詳細については、以下で詳しく説明します。

強力なワイルドカード

明示

IP バインドの弱いワイルドカード

弱いワイルドカード

ポート

0 で始まらない有効な TCP ポート番号 (1 から 65,535) を表す 10 進数の数値文字列。この値をワイルドカードにすることはできません。

relativeURI

relativeURI 要素は省略可能ですが、存在する場合は常にスラッシュ文字 ("/") を続ける必要があります。これは、スキーム、ホスト、ポートの値に対して指定されたマシンの名前空間内のサブツリーを示すプレフィックス文字列です。小文字にする必要があるスキームとは異なり、relativeURI 部分では大文字と小文字が区別されません。

適切な形式の UrlPrefixes の例を次に示します。

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

Host-Specifierカテゴリ

柔軟性と使いやすさのために、HTTP Server API では、ホストを指定する 4 つの異なる方法がサポートされています。 4 つのホスト指定子カテゴリを優先順位順に以下に示します。

強力なワイルドカード (プラス記号)

UrlPrefix のホスト要素が単一のプラス記号 (+) で構成されている場合、UrlPrefix はスキーム、port 要素、relativeURI 要素のコンテキストで使用可能なすべてのホスト名と一致し、強力なワイルドカードカテゴリに分類されます。

強力なワイルドカードは、アプリケーションが 1 つ以上の相対 URI に対応する要求を処理する必要がある場合に役立ちます。これらの要求がマシンに到着する方法や、ホストヘッダーで指定したサイトに関係なく、この状況で強力なワイルドカードを使用すると、ホストや IP アドレスの完全な一覧を指定する必要がなくなります。

明示的

ホスト要素の完全修飾ドメイン名などの明示的なホスト名は、UrlPrefix を明示的なカテゴリに配置します。この種類のホスト要素は、受信要求のホストヘッダーと直接照合されます。

明示的なホスト仕様は、要求が送信されたサイトに応じて異なるコンテンツを配信する Web サーバーなどのマルチサイトアプリケーションに役立ちます。

IP バインドの弱いワイルドカード

IP アドレスがホスト要素として表示されると、UrlPrefix は IP バインドの弱いワイルドカードカテゴリに分類されます。この種類の UrlPrefix は、指定されたスキーム、ポート、および relativeURI を持つ指定された IP インターフェイスのホスト名と一致し、厳密なワイルドカードまたは明示的な UrlPrefix によってまだ一致していません。 IP アドレスは、ホスト要素の次の 2 つの形式のいずれかを受け取ります。

IPv4 リテラル文字列: IPv4 リテラルは、192.168.0.0 などの 0 から 255 の範囲の 4 つのドット付き 10 進数で構成されます。
IPv6 リテラル文字列: IPv6 リテラル文字列は角かっこで囲まれており、コロンで区切られた 16 進数が含まれています。例: [::1] または [3ffe:ffff::6ECB:0101]。

IP バインドの弱ワイルドカードホスト指定子は、受信要求によって取得されたルートに基づいて提供されるコンテンツを変更するアプリケーションを対象としています。セキュリティを適用するために、IP バインドの弱ワイルドカードホスト指定子に依存しないでください。

弱いワイルドカード (アスタリスク)

ホスト要素としてアスタリスク (*) が表示される場合、UrlPrefix は弱いワイルドカードカテゴリに分類されます。この種類の UrlPrefix は、指定されたスキーム、ポート、および relativeURI に関連付けられているホスト名と一致します。このホスト名は、厳密なワイルドカード、明示的、または IP バインドの弱いワイルドカード UrlPrefix によってまだ一致していません。

このホスト仕様は、状況によっては既定のキャッチオールとして使用することも、多くの UrlPrefixes を使用せずに URL 名前空間の大きなセクションを指定するために使用することもできます。

予約と登録中の UrlPrefix 競合の検出

予約と登録の目的で、UrlPrefix の 4 つの異なるカテゴリは、相互に参照せずに個別に扱われます。競合する UrlPrefixes が異なるカテゴリに含まれる限り、登録できます。同じカテゴリ内でのみ競合が発生し、予約の試行が失敗します。

たとえば、明示的な UrlPrefix と競合する強力なワイルドカード UrlPrefix https://www.adatum.com:80/vroot/https://+:80/vroot/の両方を予約できます。これは、異なるカテゴリに属しているためです。ただし、それ以降、別のユーザーに予約 https://+:80/vroot/ しようとすると失敗します。これは、独自のカテゴリ内の既存の予約と競合するためです。

ルーティングの動作

受信 HTTP 要求をルーティングする場合、HTTP Server API は強力なワイルドカードカテゴリから始まり、受信 URL とそのカテゴリの登録済み UrlPrefixes と予約済みの UrlPrefixes の両方を比較します。

受信 URL が予約と一致し、登録と一致しない場合、HTTP Server API は要求を失敗させます。これにより、優先順位の低い登録で、意図されていない要求を取得できなくなります。 503 のリターンが負荷分散ゲートウェイによってサーバーが過負荷であることを示す誤って解釈されることがあるため、失敗時の状態は 503 ("サービスが利用できません") ではなく 400 ("Bad Request") です。

カテゴリ内で一致する登録が見つかった場合、その登録に関連付けられている要求キューに要求がルーティングされます。要求は常に、カテゴリ内で最も長く一致する UrlPrefix に関連付けられているキューにルーティングされます。

カテゴリに一致するものが見つからない場合、HTTP Server API は明示的なカテゴリに進み、同じ手順を繰り返します。要約すると、カテゴリを調べる順序は次のとおりです。

強力なワイルドカード
明示
弱いワイルドカードIP-Bound
弱いワイルドカード

どのカテゴリにも一致するものが見つからない場合、HTTP Server API は、要求をルーティングできないことを示す状態コードが 400 の応答を送信します。

最長一致ルール

各 UrlPrefix カテゴリ内で、HTTP Server API は、最も長い一致する UrlPrefix に関連付けられているキューに要求をルーティングします。たとえば、次の 2 つの UrlPrefixes が異なるキューに登録されるとします。

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

HTTP Server API は、の https://www.adatum.com:80/default.htm 要求を Queue1 に、要求 https://www.adatum.com:80/dir/sna/snadefault.htm を Queue2 にルーティングします。要求は https://www.adatum.com:80/dir/app.htm Queue1 にルーティングされます。最も長い完全一致は https://www.adatum.com:80/ 、UrlPrefix ではなく UrlPrefix を使用 https://www.adatum.com:80/dir/sna するためです。

次の方法で共有