您正在查看 Apigee Edge 說明文件。
查看 Apigee X 說明文件。 資訊
問題
用戶端應用程式會取得 413 Request Entity Too Large
的 HTTP 狀態碼,以及錯誤代碼 protocol.http.TooBigBody
做為 API 呼叫的回應。
錯誤訊息
用戶端應用程式會取得以下回應代碼:
HTTP/1.1 413 Request Entity Too Large
此外,您可能會遇到以下錯誤訊息:
{ "fault":{ "faultstring":"Body buffer overflow", "detail":{ "errorcode":"protocol.http.TooBigBody" } } }
可能原因
如果用戶端應用程式做為 HTTP 要求的一部分而傳送至 Apigee Edge 的酬載大小,超過 Apigee Edge 中允許的限制,就會發生這個錯誤。
以下是這項錯誤的可能原因:
原因 | 說明 | 適用的疑難排解指示 |
---|---|---|
要求酬載大小大於允許的限制 | 在 HTTP 要求中,用戶端應用程式傳送給 Apigee Edge 的酬載大小超過 Apigee Edge 允許的限制。 | Edge Public and Private Cloud 使用者 |
在解壓縮後要求酬載大小超過允許的上限 | 當用戶端應用程式向 Apigee Edge 執行 HTTP 要求時,以壓縮格式傳送的酬載大小超過 Apigee Edge 解壓縮的限制。 | Edge Public and Private Cloud 使用者 |
常見診斷步驟
請使用下列其中一種工具/技巧診斷這項錯誤:
API Monitoring
如何使用 API Monitoring 診斷錯誤:
- 以 適當角色的使用者 登入 Apigee Edge UI。
切換到要調查問題的機構
- 前往「分析」>「API 監控」>「調查」頁面。
- 請選取你發現錯誤的特定時間範圍。
- 您可以選取「Proxy」篩選器來縮小錯誤代碼的範圍。
- 將「Fault Code」與「Time」進行比較。
選取含有「Fault Code」
protocol.http.TooBigBody
和「Status Code」413
的儲存格,如下所示:錯誤代碼
protocol.http.TooBigBody
的資訊如下所示:- 按一下「查看記錄」,然後展開失敗要求的資料列。然後從「記錄檔」視窗中記下詳細資料,如下所示:
未壓縮
情境 #1:以未壓縮格式傳送酬載要求
在「記錄」視窗中,留意下列詳細資料:
- 狀態碼:
413
- Fault 資料來源:
proxy
- 錯誤代碼:
protocol.http.TooBigBody
。 - 要求長度(位元組):
15360440
(約 15 MB)
如果「Fault Source」的值為
proxy
、「Fault Code」的值為protocol.http.TooBigBody
,而「Request Length」的值超過 10 MB,就表示用戶端發出的 HTTP 要求酬載大小超過 Apigee 的允許限制。經過壓縮
情境 #2:以壓縮形式傳送的酬載要求
在「記錄檔」視窗中,記下下列詳細資料:
- 狀態碼:
413
- Fault 資料來源:
proxy
- 錯誤代碼:
protocol.http.TooBigBody
。 - 要求長度(位元組):
15264
(約 15 KB)
如果「Fault Source」的值為
proxy
、「Fault Code」的值為protocol.http.TooBigBody
,而「Request Length」小於 10 MB,則表示用戶端的 HTTP 要求酬載大小低於允許的上限,不過酬載大小超過 Apigee 解壓縮的限制。 - 狀態碼:
追蹤記錄
如何使用追蹤工具診斷錯誤:
- 啟用追蹤工作階段,並採取下列任一做法:
- 等待發生
413 Request Entity Too Large
錯誤,或 - 如果可以重現問題,請發出 API 呼叫並重現
413 Request Entity Too Large
錯誤
- 等待發生
確認已啟用「Show all Flow Infos」。
- 請選取其中一個失敗的要求,然後檢查追蹤記錄。
- 前往「Request Received from Client」階段。
未壓縮
情境 #1:以未壓縮格式傳送酬載要求
請注意下列資訊:
- Content-Encoding: 不存在
- Content-Length:
15360204
經過壓縮
情境 #2:以壓縮形式傳送的酬載要求
請注意下列資訊:
- 內容編碼:
gzip
- Content-Length:
14969
- 內容類型:
application/x-gzip
- 瀏覽追蹤記錄的不同階段,找出發生錯誤的位置。
您會在「Request Received from Client」階段之後的流程中找到錯誤,如下所示:
- 記下追蹤記錄中的錯誤值。上述追蹤記錄範例顯示:
- 錯誤:
Body buffer overflow
- error.class:
com.apigee.errors.http.user.RequestTooLarge
- 錯誤:
前往「Response Sent to Client」,並記下追蹤記錄中的錯誤值。下方的範例追蹤記錄會顯示:
- 錯誤:
413 Request Entity Too Large
- 錯誤內容:
{"fault":{"faultstring":"Body buffer overflow","detail":{"errorcode":"protocol.http.TooBigBody"}}}
- 錯誤:
- 前往追蹤記錄中的「AX」(Analytics (分析) 已記錄) 階段,然後按一下該階段。
在「階段詳細資料」部分,向下捲動至「讀取變數」。
- 確定 client.received.content.length 變數的值,代表
- 以未壓縮格式傳送要求酬載的實際大小
- Apigee 解壓縮時的要求酬載大小,是以壓縮格式傳送酬載時。一律與本案例中允許的上限 (10 MB) 相同。
未壓縮
情境 #1:以未壓縮格式要求酬載
client.received.content.length 變數:
15360204
經過壓縮
情境 #2:要求採用壓縮格式的酬載
client.received.content.length 變數:
10489856
- 下表以 client.received.content.length 變數的值為基礎,說明 Apigee 在這兩種情況中傳回
413
錯誤的原因:情境 client.received.content.length 的值 失敗原因 以未壓縮格式要求酬載 約 15 MB 大小 > 允許的大小上限為 10 MB。 以壓縮格式要求酬載 約 10 MB 解壓縮時超過大小上限
NGINX
如何使用 NGINX 存取記錄檔診斷錯誤:
- 如果您是 Private Cloud 使用者,即可使用 NGINX 存取記錄檔來判斷 HTTP
413
錯誤的相關重要資訊。 查看 NGINX 存取記錄檔:
/opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log
- 搜尋特定時間範圍內是否有任何
413
錯誤 (如果問題過去發生),或是否有任何要求仍失敗並顯示413
。 - 如果發現 X-Apigee-fault-code 與 X-Apigee-fault-code 的值相符,但發現任何
413
錯誤,請判斷 X-Apigee-fault-code 的值。未壓縮
情境 #1:以未壓縮格式要求酬載大小
以上 NGINX 存取記錄中的範例項目在「X-Apigee-fault-code」X-Apigee-fault-code 和「X-Apigee-fault-source」X-Apigee-fault-code 中,有下列值:
回應標頭 值 X-Apigee-fault-code protocol.http.TooBigBody
X-Apigee-fault-sourc policy
注意「要求長度」:
15360440
(14.6 MB > 允許的上限)經過壓縮
情境 #2:要求壓縮格式的酬載大小
以上 NGINX 存取記錄中的範例項目,有下列「X-Apigee-fault-code」X-Apigee-fault-code 和「X-Apigee-fault-source」X-Apigee-fault-code 的值:
回應標頭 值 X-Apigee-fault-code protocol.http.TooBigBody
X-Apigee-fault-source policy
請留意「要求長度」:
15264
(允許上限:14.9 K)在此情況下,即使「要求長度」低於允許的限制,Apigee Edge 仍會傳回
413
,因為要求是以壓縮格式傳送,且酬載大小超過 Apigee Edge 解壓縮的限制。
原因:要求酬載大小超過允許的上限
診斷
- 透過 API 監控、追蹤記錄工具或 NGINX 存取記錄檔,找出錯誤程式碼的「Fault Code」、「Fault 來源」和「要求酬載大小」,如情境 1 (未壓縮) 的常見診斷步驟一節所述。
- 如果「Fault Source」的值為
policy
或proxy
,就表示用戶端應用程式傳送至 Apigee 的要求酬載大小大於 Apigee Edge 中的允許限制。 - 根據步驟 1 確認「要求酬載大小」。
- 如果酬載大小超過 10 MB 的大小上限,就會導致發生錯誤。
- 如果酬載大小小於 10 MB 的許可上限,就有可能以壓縮格式傳遞要求酬載。前往 原因:在解壓縮後要求酬載大小超過允許的上限
- 您也可以按照下列步驟檢查實際要求,確認要求的酬載大小是否確實大於 10 MB 的上限:
- 如果您無法存取用戶端應用程式發出的實際要求,請前往「Resolution」。
- 如果您可以存取用戶端應用程式傳送的實際要求,請執行下列步驟:
- 驗證要求中傳遞的酬載大小。
- 如果您發現酬載的大小超過 Apigee Edge 中的限制,就是問題原因。
要求範例:
curl http://<hostalias>/testtoobigbody -k -X POST -F file=@test15mbfile -v
在上述情況中,檔案
test15mbfile
的大小約為 15 MB。如果您使用其他用戶端,請取得用戶端記錄檔,找出已傳送的酬載大小。
解析度
原因:解壓縮後的要求酬載大小超過允許的上限
如果要求酬載是以壓縮格式傳送,且要求標頭 Content-Encoding
設為 gzip,
Apigee 會解壓縮要求酬載。在解壓縮過程中,如果 Apigee 發現酬載的大小大於 10 MB,即
允許的限制,就會停止進一步解壓縮,並以 413 Request Entity Too Large
傳回錯誤代碼 protocol.http.TooBigBody
。
診斷
- 透過 API 監控、追蹤記錄工具或 NGINX 存取記錄檔,找出錯誤程式碼的「Fault Code」 、「Fault 來源」 和「要求酬載大小」 ,如常見診斷步驟 (壓縮後) 所述。
- 如果「Fault Source」的值為
policy
或proxy
,就表示用戶端應用程式傳送至 Apigee 的要求酬載大小大於 Apigee Edge 中的允許限制。 - 根據步驟 1 確認「要求酬載大小」。
- 如果酬載大小超過 10 MB 的大小上限,就會導致發生錯誤。
- 如果酬載大小小於 10 MB 的許可上限,就有可能以壓縮格式傳遞要求酬載。在這種情況下,請檢查壓縮要求酬載的未壓縮大小。
- 您可以採用下列其中一種方法,驗證來自用戶端的要求是否是以壓縮格式傳送,且未壓縮後的大小超過允許的限制:
追蹤記錄
如何使用追蹤工具進行驗證:
實際要求
如何使用實際要求進行驗證:
- 如果您無法存取用戶端應用程式發出的實際要求,請前往「Resolution」。
- 如果您可以存取用戶端應用程式傳送的實際要求,請執行下列步驟:
- 確認要求中傳遞的酬載大小,以及要求中傳送的
Content-Encoding
標頭。 檢查酬載的未壓縮大小是否超過 Apigee Edge 中的限制
要求示例:
curl https://<hostalias>/testtoobigbody -k -X POST -F file=@test15mbfile.gz -H "Content-Encoding: gzip" -v
在上述情況下,檔案
test15mbfile.gz
會小於大小上限;但是未壓縮檔案 (test15mbfile
) 的大小約為 15 MB,而Content-Encoding
標頭為gzip
。如果您使用其他用戶端,請取得用戶端記錄檔,以便找出已傳送的酬載大小,以及
Content-Encoding
標頭是否設為gzip
。
- 確認要求中傳遞的酬載大小,以及要求中傳送的
訊息處理器記錄
如何使用訊息處理器記錄進行驗證:
- 如果您是私密 Cloud 使用者,則可以使用訊息處理器記錄檔來判斷 HTTP
413
錯誤的相關重要資訊。 查看訊息處理器記錄:
/opt/apigee/var/log/edge-message-processor/logs/system.log
搜尋特定時間範圍內是否有任何
413
錯誤 (如果問題過去發生),或是否有任何要求仍因413
失敗。您可以使用下列搜尋字串:
grep -ri "chunkCount"
grep -ri "RequestTooLarge"
- 您會看到
system.log
中的幾行程式碼,類似下列內容 (TotalRead
和chunkCount
可能會依您的情況而異):2021-07-06 13:29:57,544 NIOThread@1 ERROR HTTP.SERVICE - TrackingInputChannel.checkMessageBodyTooLarge() : Message is too large. TotalRead 10489856 chunkCount 2570 2021-07-06 13:29:57,545 NIOThread@1 INFO HTTP.SERVICE - ExceptionHandler.handleException() : Exception trace: com.apigee.errors.http.user.RequestTooLarge : Body buffer overflow
- 在解壓縮程序期間,訊息處理器確認讀取位元組總數超過 10 MB 後,就會停止並顯示下列這行程式碼:
Message is too large. TotalRead 10489856 chunkCount 2570
這表示要求酬載大小超過 10 MB,且 Apigee 在大小開始超出限制的 10 MB 時,會擲回
RequestTooLarge
錯誤,錯誤代碼為protocol.http.TooBigBody
解析度
固定大小
選項 #1 [建議]:修正用戶端應用程式不要傳送酬載大小超過允許的上限
- 分析特定用戶端傳送要求 / 酬載大小超過「限制」中允許限制的原因。
如有需要,請修改用戶端應用程式,讓用戶端應用程式傳送要求 / 酬載大小不超過允許的上限。
在上述範例中,您可以傳遞較小的檔案 (假設大小為 5 MB) 的
test5mbfile
(大小為 5 MB) 酬載,即可修正問題,如下所示:curl https://<host>/testtoobigbody -k -X POST -F file=@test5mbfile -v
- 如果不需要,且您傳送的要求/酬載超出所允許的限制,請前往以下選項。
已簽署的網址格式
選項 #2 [建議]:在 Apigee Java 呼叫中使用已簽署的網址模式
對於大於 10 MB 的酬載,Apigee 建議在 Apigee Java 呼叫中使用已簽署的網址模式,如 GitHub 上的 邊緣呼叫:已簽署的網址產生器範例所示。
直播
選項 #3:使用串流功能
如果您的 API Proxy 需要處理非常大型的要求和/或回應,您可以在 Apigee 中啟用串流功能。
CwC
選項 #4:使用 CwC 屬性增加緩衝區限制
建議您只在無法使用任何建議選項時才使用這個選項,因為如果增加預設大小,可能會發生效能問題。
Apigee 提供 CwC 屬性,可讓它增加要求和回應酬載大小限制。詳情請參閱 為路由器或訊息處理器設定訊息大小限制
限制
Apigee 預期用戶端應用程式和後端伺服器傳送的酬載大小不會超過 Apigee Edge 限制中「Request/response size
」中所述的酬載大小限制。
- 如果您是公開雲端使用者,要求和回應酬載大小的上限與 Apigee Edge 限制中的
Request/response size
所述者相符。 - 如果您是 Private Cloud 使用者 ,您可能已修改要求和回應酬載大小的預設限制 (即便這不是建議做法)。 您可以按照如何檢查目前限制中的操作說明,決定要求酬載大小上限。
如何查看目前的限制?
本節說明如何確認訊息處理器中的 HTTPRequest.body.buffer.limit
屬性已更新為新值。
- 在訊息處理器機器中,在
/opt/apigee/edge-message- processor/conf
目錄中搜尋HTTPRequest.body.buffer.limit
屬性,並使用下列指令查看已設定的值:grep -ri "HTTPRequest.body.buffer.limit" /opt/apigee/edge-message-processor/conf
- 上述指令的結果範例如下:
/opt/apigee/edge-message-processor/conf/http.properties:HTTPRequest.body.buffer.limit=10m
請注意,在上述輸出範例中,請注意
HTTPRequest.body.buffer.limit
屬性已設為http.properties
中的10m
值。這表示在 Apigee 中為私有雲設定的要求酬載大小限制為 10 MB。
如果仍需要 Apigee 支援團隊的任何協助,請參閱「必須收集診斷資訊」。
必須收集診斷資訊
收集下列診斷資訊,然後與 Apigee Edge 支援團隊聯絡:
如果您是公開雲端使用者,請提供下列資訊:
- 機構組織名稱
- 環境名稱
- API Proxy 名稱
- 用來重現
413
錯誤的完整 curl 指令 - API 要求的追蹤檔
如果您是 Private Cloud 使用者,請提供下列資訊:
- 觀察失敗要求的完整錯誤訊息
- 機構組織名稱
- 環境名稱
- API Proxy 套裝組合
- 失敗 API 要求的追蹤檔
- 用來重現
413
錯誤的完整 curl 指令 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