UrlPrefix Strings（UrlPrefix 字符串）

  • 项目

在 HTTP 服务器 API 中， UrlPrefix 是一个宽字符 (UTF-16) Unicode 字符串，其规范形式指定 URL 命名空间的一部分。 它用于为用户帐户保留 URL 命名空间的一部分，或为进程注册 URL 命名空间的一部分。

UrlPrefix 格式

UrlPrefix 具有以下语法：

“scheme：//host：port/relativeURI”

UrlPrefix 的方案、主机和端口元素必须存在且不为空，并且必须遵循以下规则：

方案

必须为 http 或 https，全部为小写。

主机

必须是完全限定的域名、IPv4 或 IPv6 文本字符串或通配符。 与方案不同，方案必须为小写，主机部分不区分大小写。 根据主机部分的指定方式，UrlPrefix 属于以下四个路由类别之一，下面将更详细地介绍这些类别：

强通配符
显式
IP 绑定弱通配符
弱通配符

港口

不以零开头且表示有效 TCP 端口号 (1 到 65，535) 的十进制数字字符串。 此值不能为通配符。

relativeURI

relativeURI 元素是可选的，但如果存在，则必须始终后跟斜杠字符 (“/”) 。 这是一个前缀字符串，指示相对于方案、主机和端口值指定的计算机命名空间中的子树。 与方案（必须为小写）不同，relativeURI 部分不区分大小写。

格式正确的 UrlPrefixes 的示例包括：

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

Host-Specifier类别

为提高灵活性和易用性，HTTP 服务器 API 支持四种不同的方法来指定主机。 下面按优先级顺序列出了四个主机说明符类别：

强通配符 (加号)

当 UrlPrefix 的 host 元素由单一加号 (+) 组成时，UrlPrefix 将匹配其方案、端口和 relativeURI 元素上下文中所有可能的主机名，并属于强通配符类别。

当应用程序需要为发送到一个或多个相对 URI 的请求提供服务时，强通配符非常有用，无论这些请求如何到达计算机，或者它们在主机标头中指定的站点。 在这种情况下，使用强通配符可避免指定主机和/或 IP 地址的详尽列表。

明确

显式主机名（如 host 元素中的完全限定域名）将 UrlPrefix 置于显式类别中。 此类主机元素直接与传入请求的 Host 标头匹配。

显式主机规范对于多站点应用程序（如 Web 服务器）很有用，这些应用程序根据请求定向到的站点提供不同内容。

IP 绑定弱通配符

当 IP 地址显示为主机元素时，UrlPrefix 属于 IP 绑定弱通配符类别。 此类 UrlPrefix 将指定 IP 接口的任何主机名与指定的方案、端口和 relativeURI 匹配，并且尚未由强通配符或显式 UrlPrefix 匹配。 IP 地址在 host 元素中采用以下两种形式之一：

IPv4 文本字符串

IPv4 文本由四个点化十进制数字组成，每个数字都在 0-255 范围内，例如 192.168.0.0。

IPv6 文本字符串

IPv6 文本字符串括在方括号中，包含用冒号分隔的十六进制数;例如：[：：1] 或 [3ffe：ffff：：6ECB：0101]。

IP 绑定弱通配符主机说明符适用于根据传入请求采用的路由改变其服务内容的应用程序。 不要依赖 IP 绑定的弱通配符主机说明符来强制实施安全性。

弱通配符 (星号)

当星号 (*) 显示为主机元素时，UrlPrefix 属于弱通配符类别。 此类 UrlPrefix 与尚未由强通配符、显式或 IP 绑定弱通配符 UrlPrefix 匹配的指定方案、端口和 relativeURI 关联的任何主机名匹配。

在某些情况下，此主机规范可用作默认的 catch-all，或者可用于指定大部分 URL 命名空间，而无需使用许多 UrlPrefixes。

预留和注册期间的 UrlPrefix 冲突检测

出于预留和注册目的，将单独处理四种不同类别的 UrlPrefix，不相互引用。 只要存在冲突的 UrlPrefixes 属于不同的类别，就可以注册这些冲突的 UrlPrefixes。 只有在同一类别中，冲突才会导致预留尝试失败。

例如，可以同时保留显式 UrlPrefix https://www.adatum.com:80/vroot/ 和冲突的强通配符 UrlPrefix https://+:80/vroot/，因为它们属于不同的类别。 但是，后续尝试保留 https://+:80/vroot/ 给其他用户会失败，因为它会与其自己类别中的现有预留冲突。

路由行为

路由传入的 HTTP 请求时，HTTP 服务器 API 从强通配符类别开始，并将传入 URL 与该类别中的已注册和保留 UrlPrefixes 进行比较。

如果传入 URL 与预留匹配，但与注册匹配，则 HTTP 服务器 API 会使请求失败。 这可以防止优先级较低的注册能够选取不适合它的请求。 失败时的状态为 400 (“错误请求”) 而不是 503 (“服务不可用”) ，因为负载均衡网关有时会错误地将 503 返回解释为指示服务器过载。

如果在类别中找到匹配的注册，则请求将路由到与该注册关联的请求队列。 请求始终路由到与类别中最长匹配的 UrlPrefix 关联的队列。

如果在类别中找不到匹配项，则 HTTP 服务器 API 将转到显式类别并重复相同的过程。 总之，检查类别的顺序如下：

  1. 强通配符
  2. 显式
  3. IP-Bound弱通配符
  4. 弱通配符

如果未在任何类别中找到匹配项，HTTP 服务器 API 会发送状态代码为 400 的响应，以指示无法路由请求。

最长匹配规则

在每个 UrlPrefix 类别中，HTTP 服务器 API 将请求路由到与最长匹配 UrlPrefix 关联的队列。 例如，假设将以下两个 UrlPrefixes 注册到不同的队列：

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

HTTP 服务器 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 。