路由数据库包含预留列表。 预留列表由允许访问命名空间的用户以及预留下列出的每个用户的访问级别组成。 添加或删除预留时,将搜索路由数据库以确定访问权限。
除了检查用户 ID 外,HTTP 服务器 API 还会在安装新预留之前检查现有预留中的冲突。
添加新预留
如果 UrlPrefix 中的端口号具有不同于 UrlPrefix 中的方案的预留或注册,则注册将失败。 不能在同一端口上支持 HTTP 和 HTTPS。
找到注册的相应存储桶 (根据主机类型查看) 路由传入请求 部分。 剩余步骤是相对于此存储桶的。
选择具有与保留的 UrlPrefix 匹配的方案、主机和端口组件的预留条目。 从这些项中,找到与预留 (中不等于 relativeUri 的最长匹配 relativeUri 的条目,即 父节点) 。 如果该条目存在,则根据分配给该条目的 ACL 评估访问权限。
如果未找到父节点,则这是具有空 relativeUri 或 根预留的预留。 仅当调用方在 LocalSystem 或管理员帐户下注册时才授予访问权限。
如果授予访问权限,检查重复预留。 如果预留项具有相同的方案、端口、主机和 relativeUri,则返回ERROR_ALREADY_EXISTS代码。
注意
更新现有条目应分两个步骤执行:删除条目并添加新条目。
如果上述步骤成功,则会在预留数据库中输入新的预留条目。
注意
新条目是使用指定的 ACL 创建的,并且不会从 父 项继承 ACL。
以下示例演示了预留过程。
- 预留 1:
https://+:80/vroot/subdir/用户 A 和用户 C 的管理员成功并输入到“+”存储桶中。 - 预留 2:
https://adatum.com:80/vroot/用户 B 的管理员成功并输入到“显式主机”存储桶中。 - 预留 3:
https://adatum.com:80/vroot/subdir/otherdir/由于预留 2,用户 B 对用户 C 成功。 - 预留 4:
https://+:80/vroot/subdir/otherdir/由于预留 1,用户 A 对用户 E 成功。 - 预留 5:
https://adatum.com:80/vroot/subdir/otherdir/用户 A 为用户 E 失败。 由于预留 2 而拒绝访问。 - 预留 6:
https://+:80/vroot/subdir/用户 A 的管理员失败。 预留与预留 1 冲突。 - 预留 7:
https://adatum.com:80/newroot/用户 A 对用户 A 的预订失败。 由于 LocalSystem 或 Administrator 的隐式根预留,https://adatum.com:80/拒绝访问。
预留可能会影响传递到以前已注册 UrlPrefix 的进程的请求中的 URL 集。 例如,考虑以下情况。
- 注册:
https://adatum.com:80/vroot/按用户 A 的应用程序 1 注册。 - 的请求
https://adatum.com:80/vroot/subdir/file.htm将传递到应用程序 1。 - 预留:
https://+:80/vroot/subdir/针对用户 B。 -
https://adatum.com:80/vroot/subdir/file.htm请求现在被拒绝。 - 注册:
https://adatum.com:80/vroot/subdir/按用户 B 的应用程序 2 注册。 - 的请求
https://adatum.com:80/vroot/subdir/file.htm将传递到应用程序 2。