413 Request Entity Too Large - TooBigBody

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

問題

用戶端應用程式會收到 HTTP 狀態碼 413 Request Entity Too Large,以及錯誤碼 protocol.http.TooBigBody ,做為 API 呼叫的回應。

錯誤訊息

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

HTTP/1.1 413 Request Entity Too Large

此外,您可能會看到下列錯誤訊息:

{
   "fault":{
      "faultstring":"Body buffer overflow",
      "detail":{
         "errorcode":"protocol.http.TooBigBody"
      }
   }
}

可能原因

如果用戶端應用程式傳送至 Apigee Edge 的 HTTP 要求酬載大小,超過 Apigee Edge 允許的上限,就會發生這個錯誤。

這項錯誤的可能原因如下:

原因 說明 適用於以下裝置的疑難排解說明
要求酬載大小超過允許的上限 用戶端應用程式傳送至 Apigee Edge 的 HTTP 要求酬載大小,超過 Apigee Edge 允許的上限。 Edge 公有和私有雲使用者
要求酬載大小超過解壓縮後允許的限制 用戶端應用程式以壓縮格式傳送至 Apigee Edge 的 HTTP 要求酬載大小,經 Apigee Edge 解壓縮後,超過允許的上限。 Edge 公有和私有雲使用者

常見的診斷步驟

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

API Monitoring

如要使用 API 監控功能診斷錯誤,請按照下列步驟操作:

  1. 以具備 適當角色的使用者身分登入 Apigee Edge UI。
  2. 切換至要調查問題的機構

  3. 依序前往「Analyze」>「API Monitoring」>「Investigate」頁面。
  4. 選取您觀察到錯誤的特定時間範圍。
  5. 您可以選取「Proxy」篩選器,縮小故障代碼範圍。
  6. 繪製「錯誤代碼」與「時間」的關係圖。
  7. 選取含有「故障代碼」protocol.http.TooBigBody 和「狀態代碼」413 的儲存格,如下所示:

  8. 故障代碼 protocol.http.TooBigBody 的相關資訊會顯示如下:

  9. 按一下「查看記錄」,然後展開失敗要求的資料列。然後在「記錄」視窗中,記下詳細資料,如下所示:

    未壓縮

    情境 1:以未壓縮形式傳送要求酬載

    在「記錄」視窗中,請注意下列詳細資料:

    • 狀態碼: 413
    • 錯誤來源: proxy
    • 故障代碼: protocol.http.TooBigBody
    • 要求長度(位元組): 15360440 (~15 MB)

    如果「Fault Source」(錯誤來源) 的值為 proxy、「Fault Code」(錯誤代碼) 的值為 protocol.http.TooBigBody,且「Request Length」(要求長度) 超過 10 MB,則表示來自用戶端的 HTTP 要求酬載大小超過 Apigee 允許的上限

    經過壓縮

    情境 2:以壓縮形式傳送要求酬載

    在「記錄」視窗中,請注意下列詳細資料:

    • 狀態碼: 413
    • 錯誤來源: proxy
    • 故障代碼: protocol.http.TooBigBody
    • 要求長度(位元組): 15264 (~15 KB)

    如果「Fault Source」值為 proxy、「Fault Code」值為 protocol.http.TooBigBody,且「Request Length」小於 10 MB,表示用戶端的 HTTP 要求酬載大小低於壓縮格式的允許上限,但經 Apigee 解壓縮後,酬載大小會超過允許上限。

追蹤記錄

如要使用「追蹤」工具診斷錯誤,請按照下列步驟操作:

  1. 啟用「追蹤工作階段」,並選擇下列其中一種做法:
    • 等待發生 413 Request Entity Too Large 錯誤,或
    • 如果可以重現問題,請發出 API 呼叫並重現 413 Request Entity Too Large 錯誤
  2. 確認已啟用「Show all Flow Infos」(顯示所有流程資訊)

  3. 選取其中一個失敗的要求,然後檢查追蹤記錄。
  4. 前往「收到客戶要求」階段。

    未壓縮

    情境 1:以未壓縮形式傳送要求酬載

    請注意下列資訊:

    • Content-Encoding:不存在
    • Content-Length: 15360204

    經過壓縮

    情境 2:以壓縮形式傳送要求酬載

    請注意下列資訊:

    • Content-Encoding: gzip
    • Content-Length: 14969
    • Content-Type: application/x-gzip
  5. 瀏覽追蹤記錄的不同階段,找出發生失敗的位置。
  6. 錯誤通常會出現在「收到用戶端要求」階段之後的流程中,如下所示:

  7. 請注意追蹤記錄中的錯誤值。上述追蹤記錄樣本顯示:
    • 錯誤: Body buffer overflow
    • error.class: com.apigee.errors.http.user.RequestTooLarge
  8. 前往「Response Sent to Client」(傳送至用戶端的回應),並記下追蹤記錄中的錯誤值。下方追蹤記錄範例顯示:

    • 錯誤: 413 Request Entity Too Large
    • 錯誤內容: {"fault":{"faultstring":"Body buffer overflow","detail":{"errorcode":"protocol.http.TooBigBody"}}}
  9. 在追蹤記錄中前往「AX」(記錄的 Analytics 資料) 階段,然後按一下該階段。
  10. 在「階段詳細資料」部分,向下捲動至「讀取的變數」

  11. 判斷變數 client.received.content.length 的值,這表示:
    • 以未壓縮格式傳送要求酬載時的實際大小,以及
    • 如果酬載是以壓縮格式傳送,Apigee 解壓縮後的酬載大小。在此情境中,這個值一律會與允許的上限值 (10 MB) 相同。

    未壓縮

    情境 1:要求酬載未經壓縮

    client.received.content.length 變數:15360204

    經過壓縮

    情境 2:以壓縮格式要求酬載

    client.received.content.length 變數:10489856

  12. 下表說明在兩種情境下,Apigee 為何會根據 client.received.content.length 變數的值傳回 413 錯誤:
    情境 client.received.content.length 的值 失敗原因
    未壓縮格式的要求酬載 約 15 MB 大小超過上限 (10 MB)。
    壓縮格式的要求酬載 約 10 MB

    解壓縮後超過大小上限

NGINX

如要使用 NGINX 存取記錄診斷錯誤,請按照下列步驟操作:

  1. 如果您是私有雲使用者,可以透過 NGINX 存取記錄判斷 HTTP 413 錯誤的關鍵資訊。
  2. 檢查 NGINX 存取記錄:

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

  3. 搜尋特定時間範圍內是否有任何 413 錯誤 (如果問題發生在過去),或是否有任何要求仍會失敗並顯示 413
  4. 如果發現任何 413 錯誤,且 X-Apigee-fault-code protocol.http.TooBigBody 的值相符,請判斷 X-Apigee-fault-source 的值。

    未壓縮

    情境 1:未壓縮格式的要求酬載大小

    上述 NGINX 存取記錄檔的範例項目,X-Apigee-fault-codeX-Apigee-fault-source 的值如下:

    回應標頭
    X-Apigee-fault-code protocol.http.TooBigBody
    X-Apigee-fault-sourc policy

    請注意「要求長度」15360440 (14.6 MB 大於允許的上限)

    經過壓縮

    情境 2:要求酬載大小 (壓縮格式)

    上述 NGINX 存取記錄檔的範例項目具有下列 X-Apigee-fault-codeX-Apigee-fault-source 值:

    回應標頭
    X-Apigee-fault-code protocol.http.TooBigBody
    X-Apigee-fault-source policy

    請注意「要求長度」15264 (14.9 K < 允許的上限)

    在這種情況下,即使「要求長度」低於允許的限制,Apigee Edge 仍會傳回 413,因為要求可能是以壓縮格式傳送,且酬載大小在 Apigee Edge 解壓縮後超出限制。

原因:要求酬載大小超過允許的上限

診斷

  1. 使用 API 監控、追蹤工具或 NGINX 存取記錄,判斷觀察到的錯誤的錯誤代碼錯誤來源要求酬載大小,如常見診斷步驟的案例 1 (未壓縮) 所述。
  2. 如果「Fault Source」值為 policyproxy,表示用戶端應用程式傳送至 Apigee 的要求酬載大小,大於 Apigee Edge 允許的上限
  3. 驗證步驟 1 中判斷的「要求酬載大小」
  4. 您也可以按照下列步驟檢查實際要求,驗證要求酬載大小是否確實超過 10 MB 的允許上限:
    1. 如果無法存取用戶端應用程式提出的實際要求,請前往「解決方案」。
    2. 如果您可以存取用戶端應用程式發出的實際要求,請執行下列步驟:
      1. 確認要求中傳遞的酬載大小。
      2. 如果發現酬載大小超過 Apigee Edge 允許的上限,這就是問題的原因。
      3. 要求範例:

        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

診斷

  1. 使用 API 監控、追蹤工具或 NGINX 存取記錄,判斷所觀察到的錯誤的錯誤代碼錯誤來源 要求酬載大小,如常見診斷步驟的案例 #2 (已壓縮) 所述。
  2. 如果「Fault Source」的值為 policyproxy,表示用戶端應用程式傳送至 Apigee 的要求酬載大小,大於 Apigee Edge 允許的上限
  3. 驗證從步驟 1 判斷的「要求酬載大小」
    • 如果酬載大小超過 10 MB 的上限,就會導致錯誤。
    • 如果酬載大小小於允許的 10 MB 上限,則要求酬載可能以壓縮格式傳遞。在這種情況下,請檢查壓縮要求酬載的未壓縮大小。
  4. 如要驗證用戶端傳送的要求是否採用壓縮格式,且解壓縮後的大小是否超出允許的限制,請使用下列其中一種方法:

    追蹤記錄

    如要使用「追蹤」工具驗證,請按照下列步驟操作:

    1. 如果您已擷取失敗要求的追蹤記錄,請參閱「追蹤記錄」和「
        」中詳述的步驟。
      1. 判斷 client.received.content.length 變數的值
      2. 確認用戶端的要求是否包含 Content-Encoding: gzip 標頭
    2. 如果 client.received.content.length 變數的值大於 10 MB,即允許的上限,且要求標頭為 Content-Encoding: gzip,就會導致這個錯誤。

    實際要求

    如要使用實際要求進行驗證,請按照下列步驟操作:

    1. 如果無法存取用戶端應用程式提出的實際要求,請前往「解決方案」。
    2. 如果您可以存取用戶端應用程式發出的實際要求,請執行下列步驟:
      1. 確認要求中傳遞的酬載大小,以及要求中傳送的 Content-Encoding 標頭。
      2. 檢查酬載的未壓縮大小是否超過 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

    訊息處理器記錄

    如要使用訊息處理器記錄進行驗證,請按照下列步驟操作:

    1. 如果您是私有雲使用者,則可使用訊息處理器記錄判斷 HTTP 413 錯誤的關鍵資訊。
    2. 檢查訊息處理器記錄:

      /opt/apigee/var/log/edge-message-processor/logs/system.log

    3. 搜尋特定時間範圍內是否有任何 413 錯誤 (如果問題發生在過去),或是否有任何要求仍失敗並顯示 413

      您可以使用下列搜尋字串:

      grep -ri "chunkCount"
      
      grep -ri "RequestTooLarge"
      
    4. 您會發現 system.log 的行類似下列內容 (TotalReadchunkCount 可能因情況而異):
      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
    5. 在解壓縮過程中,只要訊息處理器判斷讀取的位元組總數 > 10 MB,就會停止並輸出以下行:
      Message is too large.  TotalRead 10489856 chunkCount 2570

      這表示「要求酬載大小」超過 10 MB,且大小開始超過 10 MB 的限制時,Apigee 會擲回 RequestTooLarge 錯誤,並將錯誤代碼設為 protocol.http.TooBigBody

解析度

修正大小

選項 1 (建議):修正用戶端應用程式,避免傳送超過允許上限的酬載大小

  1. 分析特定用戶端傳送的要求 / 酬載大小超過「限制」中定義上限的原因。
  2. 如果不希望這樣,請修改用戶端應用程式,讓傳送的要求 / 酬載大小低於允許的限制。

    在上述範例中,您可以傳遞較小的檔案 (例如 test5mbfile,大小為 5 MB) 酬載,藉此修正問題,如下所示:

    curl https://<host>/testtoobigbody -k -X POST -F file=@test5mbfile -v
    
  3. 如果需要傳送超過允許上限的要求/酬載,請參閱下一個選項。

經簽署的網址模式

選項 2 (建議):在 Apigee JavaCallout 中使用已簽署的網址模式

如果酬載大小超過 10 MB,Apigee 建議在 Apigee JavaCallout 中使用經簽署的網址模式,如 GitHub 上的 Edge Callout: Signed URL Generator 範例所示。

串流

選項 3:使用串流

如果 API Proxy 需要處理非常大的要求和/或回應,您可以在 Apigee 中啟用串流

CwC

選項 4:使用 CwC 屬性提高緩衝區限制

只有在無法使用任何建議選項時,才應使用這個選項,因為增加預設大小可能會導致效能問題。

Apigee 提供 CwC 屬性,可提高要求和回應的酬載大小上限。詳情請參閱 在路由器或訊息處理器上設定郵件大小限制

限制

Apigee 預期用戶端應用程式和後端伺服器不會傳送超過允許上限的酬載大小,如 Apigee Edge 限制Request/response size 的文件所述。

  1. 如果您是 Public Cloud 使用者,要求和回應酬載大小上限如 Request/response size 的文件所述,請參閱 Apigee Edge 限制
  2. 如果您是私有雲使用者 ,可能已修改要求和回應酬載大小的預設限制 (即使不建議這麼做)。如要判斷要求酬載大小上限,請按照「如何查看目前上限」一文中的操作說明進行。

如何查看目前的限制?

本節說明如何確認訊息處理器上的屬性 HTTPRequest.body.buffer.limit 已更新為新值。

  1. 在訊息處理器電腦上,搜尋 /opt/apigee/edge-message- processor/conf 目錄中的 HTTPRequest.body.buffer.limit 屬性,然後使用下列指令檢查已設定的值:
    grep -ri "HTTPRequest.body.buffer.limit" /opt/apigee/edge-message-processor/conf
    
  2. 上述指令的範例結果如下:
    /opt/apigee/edge-message-processor/conf/http.properties:HTTPRequest.body.buffer.limit=10m
  3. 在上述範例輸出內容中,請注意屬性 HTTPRequest.body.buffer.limit 已在 http.properties 中設為 10m 值。

    這表示在 Apigee for Private Cloud 中,要求酬載大小的上限為 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

    說明: ORGENVPORT# 會替換為實際值。

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