UrlPrefix Strings(UrlPrefix 字符串)

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

UrlPrefix 格式

UrlPrefix 具有以下语法:

"方案://host: port/relativeURI"

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

机制

必须是 http 或 https,均以小写。

主持人

必须是完全限定的域名、IPv4 或 IPv6 文本字符串或通配符。 与必须采用小写的方案不同,主机部分不区分大小写。 根据其主机部分的指定方式,UrlPrefix 分为以下四个路由类别中的一种,下面将对此进行详细介绍:

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

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

relativeURI

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

格式正确的 UrlPrefixes 的示例如下:

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

Host-Specifier 类别

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

强通配符 (加号)

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

当应用程序需要为发送到一个或多个 relativeURIs 的请求提供服务时,无论这些请求是在计算机上还是在其主机标头中指定的站点,都可以使用强通配符。 在这种情况下使用强通配符,无需指定主机和/或 IP 地址的详尽列表。

Jre

主机元素中的显式主机名(如完全限定的域名)在显式类别中放置了 UrlPrefix。 此类主机元素直接与传入请求的主机标头匹配。

显式主机规范对于多站点应用程序(如 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 匹配与指定方案、端口和 relativeURI 相关联的任何主机名,该名称尚未被强通配符、显式或 IP 绑定的弱通配符 UrlPrefix 匹配。

在某些情况下,可将此主机规范用作默认的 "全部捕获",也可以使用它来指定 URL 命名空间的大型节,而不必使用多个 UrlPrefixes。

预订和注册过程中的 UrlPrefix 冲突检测

出于预留和注册目的,将单独处理四种不同类别的 UrlPrefix,而无需彼此引用。 可以注册冲突的 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 ( "Service 不可用" ) ,因为负载平衡网关有时错误地解释了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 而不是 https://www.adatum.com:80/dir/sna UrlPrefix。