共用方式為

路由傳入要求

  • 發行項

HTTP 伺服器 API 會維護路由資料庫，以判斷哪些應用程式收到傳入要求。 路由表是從保留資料庫建置，並包含保留專案以及目前的註冊。 進行註冊或保留時，它會放入對應至主機類型的路由資料庫貯體，如下所示：

  • + ：埠註冊會放在「強式萬用字元」貯體中

  • 主機：埠註冊會放在 「明確」貯體中

  • IP：埠註冊會放在「IP 系結弱式萬用字元」貯體中

  • * ：埠註冊會放在「弱式萬用字元」貯體中

這些步驟也會參考處理傳入 HTTP 要求的順序。 先檢查強式萬用字元保留，然後檢查明確的保留，後面接著 IP 系結的弱式萬用字元和弱式萬用字元。 找到相符專案時，搜尋會停止，以便找不到任何剩餘貯體中的註冊。

HTTP Server API 路由演算法會藉由搜尋路由資料庫的註冊專案和保留專案，從強式萬用字元貯體開始，並以弱式萬用字元貯體結尾，找出 UrlPrefix 的最佳比對。 貯體內的最佳比對是 UrlPrefix (假設 URL) 主機、埠和配置部分的完全相符專案，則 UrlPrefix 的相對 URI 部分最長時間相符。 在貯體中找到相符專案之後，路由演算法會停止其搜尋，並略過所有較低的優先順序值區。

例如，請考慮下列註冊 (根據貯體類型依優先順序遞減順序列出：

  • 註冊： https://+:80/vroot/ 由應用程式 1 註冊

  • 註冊： https://adatum.com:80/ 由應用程式 2 註冊

  • 註冊： https://\*:80/ 由應用程式 3 註冊

的傳入要求 https://adatum.com:80/vroot/subdir/file.htm/ 會傳遞至應用程式 1。 的傳入要求 https://adatum.com:80/default.htm/ 會傳遞至應用程式 2。 的傳入要求 https://otheradatum.com:80/file.htm/ 會傳遞至應用程式 3。

如果最符合的是保留專案，這表示應該接收要求的應用程式未執行。 例如，請考慮下列註冊和保留：

  • 註冊： https://\*:80/vroot/ 由應用程式 1、使用者 A 註冊

  • 保留： https://adatum.com:80/ 已保留給使用者 B

的傳入要求 https://adatum.com:80/vroot/file.htm/ 不會傳遞至應用程式 1，因為最佳比對會導致使用者 B 的保留專案。在此情況下，優先順序規則會套用至優先順序較高的保留。 如果未使用任何已獲授權並註冊至所接收 URL 之服務要求的進程，則會拒絕要求， (不正確的要求) 。