HTTP サーバー API は、登録時にルーティング データベースを使用してアクセス チェックを適用します。 UrlPrefix の登録は、名前空間に登録しているユーザーがアクセス権を持っていることを確認するために、一連のアクセス チェックに合格する必要があります。 HttpAddUrl 関数を使用して、新しい登録を追加します。
HttpAddUrl で新しい登録を追加するには
- UrlPrefix のポート番号に、UrlPrefix のスキームとは異なるスキームの予約または登録がある場合、登録は失敗します。 HTTP と HTTPS は、同じポートでサポートできません。
- 登録は、登録に適したバケットにスロットされます。 バケットは、「 受信要求のルーティング 」セクションで説明されているように、URL のホストの種類に基づいています。 次の手順は、この特定のバケットに対する相対的な手順です。
- 重複する登録エントリが存在する場合は、エラー コードを返します。
- UrlPrefix と同じスキーム、ホスト、ポート コンポーネントを含む予約エントリを選択します。 ここから、 relativeUri の一致が最も長いエントリを見つけます。 エントリが存在する場合は、そのエントリに関連付けられている ACL に基づいてアクセス許可をチェックし、成功を返します。 エントリが存在しない場合は、ERROR_ALREADY_EXISTSコードを返します。
次の例は、ルーティング データベースに登録をインストールするプロセスを示しています。 ルーティング データベースには、予約 1 と予約 2 が存在します。
- 予約 1:
https://+:80/vroot/subdir/ユーザー A とユーザー C の場合。この予約は、"+" バケットに配置されます。 - 予約 2:
https://adatum.com:80/vroot/ユーザー B の場合。この予約は、"明示的なホスト" バケットに配置されます。 - 登録:
https://+:80/vroot/subdir/予約 1 が原因でユーザー B によって失敗します。 - 登録:
https://adatum.com:80/vroot/subdir/ユーザー B による予約 2 が原因で成功します。 - 登録:
https://adatum.com:80/vroot/subdir/ユーザー C によって、より明示的な予約 2 が原因で失敗します。 厳密なワイルドカード予約は、明示的な予約または登録のコンテキスト内では意味がありません。 - 登録:
https://+:80/vroot/subdir/ユーザー A による予約 1 が原因で成功します。 - 登録:
https://adatum.com:80/vroot/anotherdir/ユーザー B による予約 2 が原因で成功します。
登録のアクセスチェックには、委任特権のチェックは含まれません。 予約に基づくアクセス チェックはありません ( HttpRemoveUrl を参照)。 登録を削除するための唯一の要件は、呼び出し元のプロセスが登録を作成している必要があります。