413 Request Entity Too Large - TooBigBody

您正在查看 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 診斷錯誤:

  1. 適當角色的使用者 登入 Apigee Edge UI
  2. 切換到要調查問題的機構

  3. 前往「分析」>「API 監控」>「調查」頁面。
  4. 請選取你發現錯誤的特定時間範圍。
  5. 您可以選取「Proxy」篩選器來縮小錯誤代碼的範圍。
  6. 將「Fault Code」與「Time」進行比較。
  7. 選取含有「Fault Code」protocol.http.TooBigBody 和「Status Code」 413 的儲存格,如下所示:

  8. 錯誤代碼 protocol.http.TooBigBody 的資訊如下所示:

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

    未壓縮

    情境 #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 解壓縮的限制。

追蹤記錄

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

  1. 啟用追蹤工作階段,並採取下列任一做法:
    • 等待發生 413 Request Entity Too Large 錯誤,或
    • 如果可以重現問題,請發出 API 呼叫並重現 413 Request Entity Too Large 錯誤
  2. 確認已啟用「Show all Flow Infos」

  3. 請選取其中一個失敗的要求,然後檢查追蹤記錄。
  4. 前往「Request Received from Client」階段

    未壓縮

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

    請注意下列資訊:

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

    經過壓縮

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

    請注意下列資訊:

    • 內容編碼: gzip
    • Content-Length: 14969
    • 內容類型: application/x-gzip
  5. 瀏覽追蹤記錄的不同階段,找出發生錯誤的位置。
  6. 您會在「Request Received from Client」階段之後的流程中找到錯誤,如下所示:

  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. 下表以 client.received.content.length 變數的值為基礎,說明 Apigee 在這兩種情況中傳回 413 錯誤的原因:
    情境 client.received.content.length 的值 失敗原因
    以未壓縮格式要求酬載 約 15 MB 大小 > 允許的大小上限為 10 MB。
    以壓縮格式要求酬載 約 10 MB

    解壓縮時超過大小上限

NGINX

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

  1. 如果您是 Private Cloud 使用者,即可使用 NGINX 存取記錄檔來判斷 HTTP 413 錯誤的相關重要資訊。
  2. 查看 NGINX 存取記錄檔:

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

  3. 搜尋特定時間範圍內是否有任何 413 錯誤 (如果問題過去發生),或是否有任何要求仍失敗並顯示 413
  4. 如果發現 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 解壓縮的限制。

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

診斷

  1. 透過 API 監控、追蹤記錄工具或 NGINX 存取記錄檔,找出錯誤程式碼的「Fault Code」、「Fault 來源」和「要求酬載大小」,如情境 1 (未壓縮) 的常見診斷步驟一節所述。
  2. 如果「Fault Source」的值為 policyproxy,就表示用戶端應用程式傳送至 Apigee 的要求酬載大小大於 Apigee Edge 中的允許限制
  3. 根據步驟 1 確認「要求酬載大小」
  4. 您也可以按照下列步驟檢查實際要求,確認要求的酬載大小是否確實大於 10 MB 的上限:
    1. 如果您無法存取用戶端應用程式發出的實際要求,請前往「Resolution」
    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 存取記錄檔,找出錯誤程式碼的「Fault Code」 、「Fault 來源」 和「要求酬載大小」 ,如常見診斷步驟 (壓縮後) 所述。
  2. 如果「Fault Source」的值為 policyproxy,就表示用戶端應用程式傳送至 Apigee 的要求酬載大小大於 Apigee Edge 中的允許限制
  3. 根據步驟 1 確認「要求酬載大小」
    • 如果酬載大小超過 10 MB 的大小上限,就會導致發生錯誤。
    • 如果酬載大小小於 10 MB 的許可上限,就有可能以壓縮格式傳遞要求酬載。在這種情況下,請檢查壓縮要求酬載的未壓縮大小。
  4. 您可以採用下列其中一種方法,驗證來自用戶端的要求是否是以壓縮格式傳送,且未壓縮後的大小超過允許的限制:

    追蹤記錄

    如何使用追蹤工具進行驗證:

    1. 如果您已擷取失敗要求的追蹤記錄,請參閱 Trace
      1. 判斷 client.received.content.length 變數的值
      2. 確認用戶端的要求是否包含 Content-Encoding: gzip 標頭
    2. 如果 client.received.content.length 變數的值大於 10 MB、 允許的限制,以及要求標頭 client.received.content.length ,就是造成這個錯誤的原因。

    實際要求

    如何使用實際要求進行驗證:

    1. 如果您無法存取用戶端應用程式發出的實際要求,請前往「Resolution」
    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. 如果您是私密 Cloud 使用者,則可以使用訊息處理器記錄檔來判斷 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,且 Apigee 在大小開始超出限制的 10 MB 時,會擲回 RequestTooLarge 錯誤,錯誤代碼為 protocol.http.TooBigBody

解析度

固定大小

選項 #1 [建議]:修正用戶端應用程式不要傳送酬載大小超過允許的上限

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

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

    curl https://<host>/testtoobigbody -k -X POST -F file=@test5mbfile -v
    

  3. 如果不需要,且您傳送的要求/酬載超出所允許的限制,請前往以下選項。

已簽署的網址格式

選項 #2 [建議]:在 Apigee Java 呼叫中使用已簽署的網址模式

對於大於 10 MB 的酬載,Apigee 建議在 Apigee Java 呼叫中使用已簽署的網址模式,如 GitHub 上的 邊緣呼叫:已簽署的網址產生器範例所示。

直播

選項 #3:使用串流功能

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

CwC

選項 #4:使用 CwC 屬性增加緩衝區限制

建議您只在無法使用任何建議選項時才使用這個選項,因為如果增加預設大小,可能會發生效能問題。

Apigee 提供 CwC 屬性,可讓它增加要求和回應酬載大小限制。詳情請參閱 為路由器或訊息處理器設定訊息大小限制

限制

Apigee 預期用戶端應用程式和後端伺服器傳送的酬載大小不會超過 Apigee Edge 限制中「Request/response size」中所述的酬載大小限制。

  1. 如果您是公開雲端使用者,要求和回應酬載大小的上限與 Apigee Edge 限制中的 Request/response size 所述者相符。
  2. 如果您是 Private Cloud 使用者 ,您可能已修改要求和回應酬載大小的預設限制 (即便這不是建議做法)。 您可以按照如何檢查目前限制中的操作說明,決定要求酬載大小上限。

如何查看目前的限制?

本節說明如何確認訊息處理器中的 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 中為私有雲設定的要求酬載大小限制為 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