本頁面由 Cloud Translation API 翻譯而成。

500 內部伺服器錯誤 - BadPath

您正在查看 Apigee Edge 說明文件。
查看 Apigee X 說明文件。資訊

問題

用戶端應用程式會取得 500 Internal Server Error 的 HTTP 狀態碼，以及錯誤代碼 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 節：路徑：

URI 語法 包含下列元件：

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

path 是必要元件，且元件的開頭和必須一律有正斜線 (/)。

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

例如：如果 target.url 的值為 https://www.mocktarget.apigee.net?json，當 path 發現該 path 無效，就會發生這個錯誤，因為開頭是問號 (?)，而不是正斜線 (/)。

原因	說明	適用的疑難排解指示
後端伺服器網址 (target.url) 的路徑無效	以流程變數 `target.url` 表示的後端伺服器網址路徑元件會以半形問號 (`?`) 開頭，而非正斜線 (`/`)。	Edge Public and Private Cloud 使用者

常見診斷步驟

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

API Monitoring

程序 #1：使用 API 監控功能

如何使用 API Monitoring 診斷錯誤：

以適當角色的使用者登入 Apigee Edge UI。
切換至您想要調查問題的機構。
前往「分析」>「API 監控」>「調查」頁面。
請選取你發現錯誤的特定時間範圍。
將「Fault Code」與「Time」進行比較。

注意：您也可以依據「Time」繪製「Status Code」。
選取含有錯誤代碼 protocol.http.BadPath 的儲存格，如下所示：
錯誤代碼 protocol.http.BadPath 的資訊如下所示：
按一下「查看記錄」，然後展開失敗要求的資料列。
在「記錄檔」視窗中記下下列詳細資料：
- 狀態碼： 500
- Fault 資料來源： target
- 錯誤代碼： protocol.http.BadPath
如果「Fault Source」為 target，且「Fault Code」為 protocol.http.BadPath，則表示後端伺服器網址具有無效路徑。

追蹤記錄

程序 2：使用追蹤工具

如何使用追蹤工具診斷錯誤：

啟用追蹤工作階段，並採取下列任一做法：
- 等待發生 500 Internal Server Error 錯誤，或
- 如果可以重現問題，請透過 API 呼叫來重現問題 500 Internal Server Error
確保已啟用「Show all FlowInfos」：
請選取其中一個失敗的要求，然後檢查追蹤記錄。
瀏覽追蹤記錄的不同階段，找出發生錯誤的位置。
您會在「目標要求流程開始」階段之後的流程中找到錯誤，如下所示：
記下追蹤記錄中的錯誤值：

錯誤：要求路徑無效

由於 Apigee Edge 在「目標要求流程開始」階段之後會引發錯誤，因此後端伺服器網址具有無效路徑。如果 Apigee Edge 中的流程變數 target.url (代表後端伺服器的網址) 可能已透過目標要求流程中的任一政策更新，且路徑無效，就可能會發生這種情況。
從錯誤流程向後檢查每個流程中的「已讀取和指派的變數」部分，往「目標要求流程開始」階段。
決定政策，且資料流變數 target.url 已更新：
顯示 JavaScript 政策更新流程變數 target.url: 的範例追蹤記錄

請注意，在上方顯示的追蹤記錄範例中，系統會在名為 JS- SetTargetURL 的 JavaScript 政策中，更新流程變數變數 target.url 的值，如下所示： target.url : https://mocktarget.apigee.net?json
請注意，target.url 中的值具備下列元件：
- 配置： https
- authority： mocktarget.apigee.net
- path： ?json
由於 path 元件是以半形問號 (?) 開頭，而非正斜線 (/)，因此您會收到錯誤 Invalid request path。
前往追蹤記錄中的「AX」(Analytics (分析) 已記錄) 階段，然後按一下該階段。
向下捲動至「階段詳細資料」-「錯誤標頭」區段，確定「X-Apigee-fault-code」和「X-Apigee-fault-source」的值，如下所示：

您將分別看到 X-Apigee-fault-code 和 X-Apigee-fault-source 的值為 protocol.http.BadPath 和 target ，表示這個錯誤是因後端伺服器網址的路徑無效所致。

回應標頭	值
X-Apigee-fault-code	`protocol.http.BadPath`
X-Apigee-fault-source	`target`

NGINX

程序 3：使用 NGINX 存取記錄檔

如何使用 NGINX 存取記錄檔診斷錯誤：

如果您是 Private Cloud 使用者，即可使用 NGINX 存取記錄檔來判斷 HTTP 500 Internal Server Error 的重要資訊。
查看 NGINX 存取記錄檔：

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

注意：以實際值取代 ORG、ENV 和 PORT#。
搜尋特定時間範圍內 (如果問題過去發生)，或是否有任何要求仍失敗並顯示 500 錯誤代碼500與錯誤代碼 protocol.http.BadPath。

如果在符合 X-Apigee-fault-code 值的 X-Apigee-fault-code 時發現任何 500 錯誤，請判斷 X-Apigee-fault-code 的值。

NGINX 存取記錄中的 500 錯誤範例：

上述 NGINX 存取記錄範例中的「X-Apigee- error-code」和「X-Apigee-fault-source」的值如下：

標頭	值
X-Apigee-fault-code	`protocol.http.BadPath`
X-Apigee-fault-source	`target`

請注意，X-Apigee-fault-code 和 X-Apigee-fault-source 的值分別為 protocol.http.BadPath 和 target ，表示這項錯誤是由於後端伺服器網址具有無效路徑所致。

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

診斷

使用 API 監控、追蹤工具或 NGINX 存取記錄檔，按照常見診斷步驟的說明，判斷 500 Internal Server Error 的「Fault Code」和「Fault 來源」。
如果「Fault Code」為 protocol.http.BadPath，且「Fault Source」的值為 target，就表示後端伺服器網址含有無效路徑。
後端伺服器網址會以 Apigee Edge 中的流程變數 target.url 表示。當您嘗試在目標要求流程中使用任何政策 (在 Proxy/共用流程內) 更新後端伺服器網址 (target.url) 時，通常就會發生這個錯誤。

注意：依據網址規格 RFC 3986 第 3.3 節：路徑，如果路徑開頭為問號 (?) 而非正斜線 (/)，Apigee Edge 會將後端伺服器網址中的 path 視為「無效」。
請使用以下其中一種方法判斷資料流變數 target.url 是否含有「無效」路徑及其值的來源：
追蹤記錄

使用追蹤記錄工具

如果您已擷取這個錯誤的追蹤記錄，請依照使用追蹤記錄工具中的說明步驟，並且
1. 確認 target.url 路徑無效，也就是開頭為問號 (?)，而非正斜線 (/)。
2. 如果是，請找出修改或更新 target.url 值以包含無效路徑的政策。
  
  顯示 JavaScript 政策更新流程變數 target.url 的範例追蹤記錄
3. 請注意，在上述追蹤記錄範例中，JavaScript 政策已修改或更新 target.url 的值，以加入無效路徑。
4. 請注意，target.url 包含下列元件：
  - 配置： https
  - authority： mocktarget.apigee.net
  - path： ?json
  路徑以問號 (?) 開頭，而不是正斜線 (/) ，因此無效。
記錄檔

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

查看失敗的 API Proxy

如果沒有這個錯誤的追蹤記錄或記錄檔，請查看失敗的 API Proxy，找出修改或更新流程變數 target.url 以包含無效路徑的內容。請檢查下列事項：
- API Proxy 中的政策
- 從 Proxy 叫用的任何共用流程
仔細檢查特定政策 (例如 AssignMessage 或 JavaScript) 會修改或更新流程變數 target.url，並判斷更新 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
- path： ?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);
```
在上述範例中，請注意，藉由串連變數 url 中的 https://mocktarget.apigee.net 值和另一個變數 path 的值 (系統會擷取該變數的值從 request.header.Path. 擷取)，藉此更新資料流變數 target.url

如果您可以存取實際要求或追蹤記錄，就可以驗證傳遞至 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
- path： ?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
- path： ?echo
在此範例中，路徑是以問號 (?) 開頭，而不是正斜線 (/)，因此「無效」。因此，Apigee Edge 會傳回 500 Internal Server Error 的錯誤代碼 protocol.http.BadPath。

解析度

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

確認以流程變數 target.url 表示的後端伺服器網址，一律具有有效路徑，且開頭一律為正斜線 (/)。
1. 在某些情況下，路徑中可能沒有資源名稱，因此請確保路徑至少包含正斜線 (/)。
2. 如果您使用其他變數來判斷流程變數 target.url 的值，請確認其他變數不含無效路徑。
3. 如果您執行任何字串作業來決定流程變數 target.url 的值，請確定字串運算的結果或結果不含無效路徑。
在上述範例中，您可以依照以下的說明修正此問題：
範例 #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);
```
請務必傳遞有效路徑，例如將 /user 納入要求標頭 Path 中，以修正這個問題，如下所示：

要求範例：
```
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 名稱
- 完成 curl 指令，用來重現 500 Internal Server Error 錯誤代碼 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
參考資料

流程變數 - 指定目標

500 內部伺服器錯誤 - BadPath

問題

錯誤訊息

可能原因

常見診斷步驟

API Monitoring

追蹤記錄

NGINX

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

診斷

追蹤記錄

記錄檔

API Proxy

範例 #1

範例 #2

範例 #3

解析度

範例 #1

範例 #2

範例 #3

規格

必須收集診斷資訊

參考資料