UrlPrefix 字串

發行項
06/13/2023

在 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 的主機元素包含單一加號 (+) 時，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。只有在相同的類別內，才會發生衝突，導致保留嘗試失敗。

例如，可以保留明確的 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 伺服器 API 會將的要求 https://www.adatum.com:80/default.htm 路由傳送至 Queue1，以及對 Queue2 的要求 https://www.adatum.com:80/dir/sna/snadefault.htm 。它會將的要求 https://www.adatum.com:80/dir/app.htm 路由傳送至 Queue1， https://www.adatum.com:80/dir/sna 因為最長的完整比對與 UrlPrefix 不搭配 https://www.adatum.com:80/ UrlPrefix。