UrlPrefix Strings (UrlPrefix 文字列)

  • [アーティクル]

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 は明示的なカテゴリに進み、同じ手順を繰り返します。 要約すると、カテゴリを調べる順序は次のとおりです。

  1. 強力なワイルドカード
  2. 明示
  3. 弱いワイルドカードIP-Bound
  4. 弱いワイルドカード

どのカテゴリにも一致するものが見つからない場合、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 するためです。