UrlPrefix 字串

發行項
03/13/2025

在 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 元素內容中的所有可能主機名，並屬於強通配符類別。

當應用程式需要提供尋址至一或多個relativeURIs的要求時，強式通配符就很有用，無論這些要求如何抵達電腦或他們在主機標頭中指定的網站。在此情況下，強式通配符的使用可避免需要指定完整的主機和/或IP位址清單。

明確

明確主機名，例如主機元素中完整功能變數名稱，會將UrlPrefix放在明確類別中。這種主機專案會直接比對連入要求的 Host 標頭。

明確主機規格適用於多網站應用程式，例如根據要求導向的月臺，提供不同內容的 Web 伺服器。

IP 系結弱式通配符

當IP位址顯示為主機元素時，UrlPrefix 會落入IP系結的弱式通配符類別。這種 UrlPrefix 會比對具有指定配置、埠和 relativeURI 之指定 IP 介面的任何主機名，而且尚未與強通配符或明確 UrlPrefix 相符。 IP 位址會採用主機元素中的兩種形式之一：

IPv4 常值字串: IPv4 常值包含四個點十進位數，每個數位範圍都是 0-255，例如 192.168.0.0。
IPv6 常值字串: IPv6 常值字串會以方括弧括住，並包含以冒號分隔的十六進位數位：例如：[：：1] 或 [3ffe：ffff：：6ECB：0101]。

IP 系結弱式通配符主機規範適用於應用程式，這些應用程式會根據傳入要求所採取的路由來改變其服務內容。請勿依賴IP系結弱式通配符主機規範來強制執行安全性。

弱通配符（星號）

當星號 \ 顯示為主元素時，UrlPrefix 會進入弱式通配符類別。這種 UrlPrefix 會比對與指定配置、埠和 relativeURI 相關聯的任何主機名，且尚未與強通配符、明確或 IP 系結弱式通配符 UrlPrefix 相符。

在某些情況下，此主機規格可作為預設的 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 會繼續進行明確的類別，並重複相同的程式。總結來說，檢查類別的順序如下：

強通配符
明確
IP-Bound 弱式通配符
弱式通配符

如果在任何類別中找不到相符專案，HTTP 伺服器 API 會傳送狀態代碼為 400 的回應，以指出無法路由傳送要求。

最長比對規則

在每個 UrlPrefix 類別內，HTTP 伺服器 API 會將要求路由傳送至與最長相符 UrlPrefix 相關聯的佇列。例如，假設下列兩個 UrlPrefixes 會註冊到不同的佇列：

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

HTTP Server 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。

共用方式為