500 內部伺服器錯誤 - BadPath

您目前查看的是 Apigee Edge 說明文件。
前往 Apigee X 說明文件。 info

問題

用戶端應用程式會收到 HTTP 狀態碼 500 Internal Server Error，以及錯誤碼 protocol.http.BadPath，做為 API 呼叫的回應。

錯誤訊息

用戶端應用程式會取得下列回應代碼：

HTTP/1.1 500 Internal Server Error

此外，您可能會看到下列錯誤訊息：

{
   "fault":{
      "faultstring":"Invalid request path",
      "detail":{
         "errorcode":"protocol.http.BadPath"
      }
   }
}

可能原因

如果後端伺服器的要求網址 (以流程變數 target.url 表示) 包含以問號 (?) 開頭的 path ，而非正斜線 (/)，就會發生這個錯誤，因為這是無效的。

根據規格 RFC 3986 第 3 節：語法元件和 RFC 3986 第 3.3 節：路徑：

1. URI 語法 包含下列元件：

           foo://example.com:8042/over/there?name=ferret#nose
           \_/   \______________/\_________/ \_________/ \__/
            |            |            |            |       |
         scheme      authority       path        query   fragment
   

2. path 元件為必要元件，且必須以正斜線 (/) 開頭，並一律包含正斜線。

因此，如果後端伺服器的要求網址含有以問號 (?) 開頭的 path 元件，而非正斜線 (/)，Apigee Edge 會傳回 500 Internal Server Error 和錯誤代碼 protocol.http.BadPath。

舉例來說，如果 target.url 的值為 https://www.mocktarget.apigee.net?json，則會發生此錯誤，因為系統發現 path無效，因為該值是以問號 (?) 開頭，而非正斜線 (/)。

常見的診斷步驟

請使用下列其中一種工具/技術診斷這項錯誤：

原因：後端伺服器網址 (target.url) 的路徑無效

診斷

1. 如「常見診斷步驟」一文所述，使用 API 監控、追蹤工具或 NGINX 存取記錄，找出 500 Internal Server Error 的錯誤代碼和錯誤來源。
2. 如果「錯誤代碼」為 protocol.http.BadPath，且「錯誤來源」的值為 target，表示後端伺服器網址的路徑無效。

3. 後端伺服器網址在 Apigee Edge 中以流程變數 target.url 表示。如果您嘗試使用目標要求流程中的任何政策 (在 Proxy/共用流程中)，動態更新後端伺服器網址 (target.url)，導致網址路徑無效，通常就會發生這項錯誤。

4. 使用下列其中一種方法，判斷流程變數 target.url 是否確實有無效 路徑，以及其值的來源：

   追蹤記錄

   使用 Trace 工具

   如果您已擷取這項錯誤的追蹤記錄，請按照「使用追蹤記錄工具 」和

   1. 確認 target.url 的路徑是否無效，也就是開頭為半形問號 (?) 而非正斜線 (/)。

   2. 如果是，請找出修改或更新 target.url 值的政策，確認該值是否包含無效路徑。

      範例追蹤記錄：顯示 JavaScript 政策更新了流程變數 target.url

      
   3. 在上述範例追蹤記錄中，請注意 JavaScript 政策已修改或更新 target.url 的值，使其包含無效路徑。
   4. 請注意，target.url 包含下列元件：
      • 配置： https
      • authority： mocktarget.apigee.net
      • 路徑： ?json

      路徑開頭為問號 (?)，而非正斜線 (/)， 因此無效。

   記錄

   使用記錄伺服器中的記錄

   1. 如果沒有這個錯誤的追蹤記錄 (間歇性問題)，請檢查您是否已使用 MessageLogging 或 ServiceCallout 等政策，將流程變數 target.url 的值相關資訊記錄到記錄伺服器。
   2. 如果您有記錄，請查看記錄並
      1. 確認 target.url 是否有路徑無效，以及
      2. 查看是否可以判斷哪個政策修改了 target.url，導致路徑無效

   API Proxy

   查看失敗的 API Proxy

   如果沒有這項錯誤的追蹤記錄或記錄檔，請檢查失敗的 API Proxy，判斷是哪個項目修改或更新流程變數 target.url，導致其中包含無效路徑。請檢查下列事項：

   • API Proxy 中的政策
   • 從 Proxy 叫用的任何共用流程

5. 請仔細檢查修改或更新流程變數 target.url 的特定政策 (例如：AssignMessage 或 JavaScript)，並判斷 target.url 更新為無效路徑的原因。

   以下是幾個政策範例，這些政策會以錯誤方式更新流程變數 target.url，導致該變數含有無效路徑，進而造成這項錯誤。

   範例 #1

   範例 1：JavaScript 政策更新 target.url 變數

   var url = "https://mocktarget.apigee.net?json"
   context.setVariable("target.url", url);

   在上述範例中，請注意資料流變數 target.url 會以另一個變數 url. 中包含的值 https://mocktarget.apigee.net?json 更新

   請注意，url 的值包含下列元件：

   • 配置： https
   • authority： mocktarget.apigee.net
   • 路徑： ?json

   路徑開頭為問號 (?) 而非正斜線 (/)，這是無效的。因此，Apigee Edge 會傳回 500 Internal Server Error，並顯示錯誤代碼 protocol.http.BadPath。

   範例 #2

   範例 2：JavaScript 政策根據要求標頭中的值更新 target.url 變數

   var path = context.getVariable("request.header.Path");
   var url = "https://mocktarget.apigee.net" + path
   context.setVariable("target.url", url);

   在上述範例中，請注意，流程變數 target.url 會透過串連變數 url 中包含的值 https://mocktarget.apigee.net 和另一個變數 path 的值來更新，而後者的值是從 request.header.Path. 擷取。

   如果您可以存取實際要求或追蹤記錄，就能驗證傳遞至 request.header.Path 的實際值。

   使用者提出的要求範例

   curl -v https://HOST_ALIAS/v1/myproxy -H "Authorization: Bearer <token> -H "Path: ?user"
   

   在本範例中，標頭路徑不會隨要求一併傳送。因此，JavaScript 政策中變數 path 的值為 null。

   舉例來說：

   • url = https://mocktarget.apigee.net + path
   • url = https://mocktarget.apigee.net + "?user"
   • target.url = https://mocktarget.apigee.net?user

   請注意，target.url 的值包含下列元件：

   • 配置： https
   • authority： mocktarget.apigee.net
   • 路徑： ?user

   路徑開頭為問號 (?) 而非正斜線 (/)，這是無效的。因此，Apigee Edge 會傳回 500 Internal Server Error，錯誤代碼為 protocol.http.BadPath。

   範例 #3

   範例 #3：更新 AssignMessage 政策的 target.url 變數

   <AssignMessage async="false" continueOnError="false" enabled="true" name="AM-SetTargetURL">
       <DisplayName>AM-SetTargetURL</DisplayName>
       <AssignVariable>
            <Name>target.url</Name>
            <Value>https://mocktarget.apigee.net?echo</Value>
       </AssignVariable>
       <IgnoreUnresolvedVariables>true</IgnoreUnresolvedVariables>
       <AssignTo createNew="false" transport="http" type="request"/>
   </AssignMessage>

   請注意，url 的值包含下列元件：

   • 配置： https
   • authority： mocktarget.apigee.net
   • 路徑： ?echo

   同樣在這個範例中，路徑是以問號 (?) 開頭，而非正斜線 (/)，這是無效的。因此，Apigee Edge 會傳回 500 Internal Server Error，並顯示錯誤代碼 protocol.http.BadPath。

解析度

根據網址規格 RFC 3986 第 3 節：語法元件，path 元件為必要，且一律須以「/」開頭。因此，請按照下列步驟修正這個問題：

1. 請確保後端伺服器網址 (以流程變數 target.url 表示) 一律具有有效路徑，且開頭一律為斜線 (/)。
   1. 在某些情況下，路徑中可能沒有資源名稱，請確保路徑至少有一個正斜線 (/)。
   2. 如果您使用任何其他變數來判斷流程變數 target.url 的值，請確保其他變數沒有無效路徑。
   3. 如果您執行任何字串作業來判斷流程變數 target.url 的值，請確保字串作業的結果或輸出內容沒有無效路徑。

2. 在上述範例中，您可以按照下列說明修正這個問題：

   範例 #1

   範例 1：JavaScript 政策更新 target.url 變數

   在 url 變數中使用正斜線 (/) 取代問號 (?)，即可修正這個問題，如下所示：

   var url = "https://mocktarget.apigee.net/json"
   context.setVariable("target.url", url);

   範例 #2

   範例 2：JavaScript 政策根據要求標頭中的值更新 target.url 變數

   var path = context.getVariable("request.header.Path");
   var url = "https://mocktarget.apigee.net" + path
   context.setVariable("target.url", url);

   請確認您傳遞的是有效路徑，例如：要求標頭 Path 中的 /user，以修正這個問題，如下所示：

   要求範例：

   curl -v https://HOST_ALIAS/v1/myproxy -H "Authorization: Bearer <token> -H "Path: /user"
   

   範例 #3

   範例 #3：更新 AssignMessage 政策的 target.url 變數

   在 AssignMessage 政策的 <Value> 元素中新增有效路徑。 也就是說，請將 <Value> 元素中的問號 (?) 替換為 正斜線 (/) ，並將其設為 https://mocktarget.apigee.net/echo，即可修正這個問題，如下所示：

   <AssignMessage async="false" continueOnError="false" enabled="true" name="AM-SetTargetURL">
       <DisplayName>AM-SetTargetURL</DisplayName>
       <AssignVariable>
            <Name>target.url</Name>
            <Value>https://mocktarget.apigee.net/echo</Value>
       </AssignVariable>
       <IgnoreUnresolvedVariables>true</IgnoreUnresolvedVariables>
       <AssignTo createNew="false" transport="http" type="request"/>
   </AssignMessage>

   規格

   根據下列規格，Apigee Edge 預期後端伺服器網址中的path 元件 一律必須以正斜線 (/) 開頭：

   規格
   RFC 3986 第 3 節：語法元件
   RFC 3986 第 3.3 節：路徑

   如果仍需要 Apigee 支援團隊協助，請參閱「必須收集診斷資訊」。

   必須收集診斷資訊

   如果按照上述指示操作後問題仍未解決，請收集下列診斷資訊，然後與 Apigee Edge 支援團隊聯絡：

   如果您是公有雲使用者，請提供下列資訊：

   • 機構名稱
   • 環境名稱
   • API Proxy 名稱
   • 用於重現 500 Internal Server Error 的完整 curl 指令，以及錯誤代碼 protocol.http.BadPath
   • API 要求的追蹤記錄檔

   如果您是 Private Cloud 使用者，請提供下列資訊：

   • 失敗要求顯示的完整錯誤訊息
   • 環境名稱
   • API Proxy 套裝組合
   • API 要求的追蹤記錄檔

   • NGINX 存取記錄：

     /opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log

     說明： ORG、ENV 和 PORT# 會替換為實際值。

   • 訊息處理器系統記錄 /opt/apigee/var/log/edge-message- processor/logs/system.log

   參考資料

   流程變數 - 目標