受信要求のルーティング

HTTP Server API は、受信要求を受信するアプリケーションを決定するためのルーティング データベースを保持します。 ルーティング テーブルは予約データベースから作成され、予約エントリと現在の登録が含まれます。 登録または予約が行われると、次のようにホストの種類に対応するルーティング データベース バケットに配置されます。

• + : ポート登録は "強力なワイルドカード" バケットに配置されます

• host : ポート登録は "Explicit" バケットに配置されます

• IP: ポート登録は "IP バインドの弱いワイルドカード" バケットに配置されます

• * : ポートの登録は、"弱いワイルドカード" バケットに配置されます

これらの手順では、受信 HTTP 要求が処理される順序も参照します。 最初に強力なワイルドカード予約が確認され、その後に明示的な予約がチェックされ、その後に IP バインドの弱いワイルドカードと弱いワイルドカードが続きます。 一致が見つかると検索が停止し、残りのバケットの登録が見つからないようにします。

HTTP Server API ルーティング アルゴリズムは、ルーティング データベースの登録エントリと予約エントリの両方を検索し、強力なワイルドカード バケットから始まり、弱いワイルドカード バケットで終わることで、 UrlPrefix に最適な一致を見つけます。 バケット内の最適な一致は、UrlPrefix の相対 URI 部分の最長一致です (URL のホスト、ポート、スキームの部分と完全に一致すると仮定します)。 バケットで一致するものが見つかった後、ルーティング アルゴリズムは検索を停止し、優先順位の低いバケットをすべてスキップします。

たとえば、次の登録について考えてみましょう (バケットの種類に基づいて優先順位の降順で一覧表示されます)。

• 登録: https://+:80/vroot/ アプリケーション 1 によって登録されます

• 登録: https://adatum.com:80/ アプリケーション 2 によって登録されます

• 登録: https://\*:80/ アプリケーション 3 によって登録されます

の受信要求 https://adatum.com:80/vroot/subdir/file.htm/ がアプリケーション 1 に配信されます。 の受信要求 https://adatum.com:80/default.htm/ は、アプリケーション 2 に配信されます。 の受信要求 https://otheradatum.com:80/file.htm/ がアプリケーション 3 に配信されます。

最適な一致が予約エントリの場合は、要求を受信する必要があるアプリケーションが実行されていないことを意味します。 たとえば、次の登録と予約について考えてみましょう。

• 登録: https://\*:80/vroot/ アプリケーション 1 で登録され、ユーザー A

• 予約: https://adatum.com:80/ ユーザー B 用に予約されています

の受信要求 https://adatum.com:80/vroot/file.htm/ は、ユーザー B の予約エントリに最も一致するため、アプリケーション 1 に配信されません。優先順位規則は、優先順位が高い予約に適用されます。 承認され、受信した URL のサービス要求に登録されているプロセスがアクティブでない場合、要求は 400 状態コード (無効な要求) で拒否されます。