413 Thực thể yêu cầu quá lớn – TooBigBody

Bạn đang xem tài liệu về Apigee Edge.
Truy cập vào tài liệu Apigee X. thông tin

Dấu hiệu

Ứng dụng khách nhận được mã trạng thái HTTP 413 Request Entity Too Large với mã lỗi protocol.http.TooBigBody làm phản hồi cho các lệnh gọi API.

Thông báo Lỗi

Ứng dụng khách nhận được mã phản hồi sau: 

HTTP/1.1 413 Request Entity Too Large

Ngoài ra, bạn có thể thấy thông báo lỗi sau: 

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

Các nguyên nhân có thể

Lỗi này xảy ra nếu kích thước tải trọng do ứng dụng khách gửi đến Apigee Edge trong yêu cầu HTTP lớn hơn hạn mức cho phép trong Apigee Edge .

Sau đây là những nguyên nhân có thể gây ra lỗi này :

Nguyên nhân Mô tả Hướng dẫn khắc phục sự cố áp dụng cho
Kích thước tải trọng yêu cầu lớn hơn giới hạn cho phép Kích thước tải trọng do ứng dụng gửi dưới dạng một phần của yêu cầu HTTP đến Apigee Edge lớn hơn giới hạn cho phép trong Apigee Edge. Người dùng Edge Public Cloud và Private Cloud
Kích thước tải trọng yêu cầu vượt quá giới hạn cho phép sau khi giải nén Kích thước tải trọng do ứng dụng khách gửi ở định dạng nén trong yêu cầu HTTP đến Apigee Edge lớn hơn giới hạn cho phép khi được Apigee Edge giải nén. Người dùng Edge Public Cloud và Private Cloud

Các bước chẩn đoán thường gặp

Hãy sử dụng một trong các công cụ/kỹ thuật sau để chẩn đoán lỗi này:

Giám sát API

Cách chẩn đoán lỗi bằng tính năng Giám sát API:

  1. Đăng nhập vào giao diện người dùng Apigee Edge với tư cách là người dùng có vai trò phù hợp.

  2. Chuyển sang tổ chức mà bạn muốn điều tra vấn đề

  3. Chuyển đến trang Phân tích > Giám sát API > Điều tra.
  4. Chọn khung thời gian cụ thể mà bạn nhận thấy lỗi.
  5. Bạn có thể chọn bộ lọc Proxy để thu hẹp phạm vi mã lỗi.
  6. Vẽ Mã lỗi theo Thời gian.

  7. Chọn một ô có Mã lỗi protocol.http.TooBigBody và Mã trạng thái 413 như minh hoạ bên dưới:

  8. Thông tin về mã lỗi protocol.http.TooBigBody sẽ xuất hiện như hình dưới đây:

  9. Nhấp vào Xem nhật ký rồi mở rộng hàng của yêu cầu không thực hiện được. Sau đó, trong cửa sổ Logs (Nhật ký), hãy lưu ý các thông tin chi tiết như minh hoạ bên dưới :

    Không nén

    Trường hợp 1: Tải trọng yêu cầu được gửi ở dạng chưa nén

    Trong cửa sổ Nhật ký, hãy lưu ý những thông tin sau:

    • Mã trạng thái: 413
    • Nguồn lỗi: proxy
    • Mã lỗi: protocol.http.TooBigBody.
    • Độ dài yêu cầu(byte): 15360440 (~15 MB)

    Nếu Nguồn lỗi có giá trị proxy, Mã lỗi có giá trị protocol.http.TooBigBody và Độ dài yêu cầu lớn hơn 10 MB, thì điều đó có nghĩa là yêu cầu HTTP từ ứng dụng có kích thước tải trọng yêu cầu lớn hơn hạn mức cho phép trong Apigee.

    Đã nén

    Tình huống 2: Tải trọng yêu cầu được gửi ở dạng nén

    Trong cửa sổ Nhật ký, hãy lưu ý những thông tin sau:

    • Mã trạng thái: 413
    • Nguồn lỗi: proxy
    • Mã lỗi: protocol.http.TooBigBody.
    • Độ dài yêu cầu(byte): 15264 (~15 kB)

    Nếu Nguồn lỗi có giá trị proxy, Mã lỗi có giá trị protocol.http.TooBigBody và Độ dài yêu cầu nhỏ hơn 10 MB, thì điều này cho thấy yêu cầu HTTP từ ứng dụng có kích thước tải trọng yêu cầu nhỏ hơn giới hạn cho phép ở định dạng nén, nhưng kích thước tải trọng lớn hơn giới hạn cho phép khi Apigee giải nén.

Trace

Cách chẩn đoán lỗi bằng công cụ Trace (Theo dõi):

  1. Bật phiên theo dõi và một trong hai
    • Chờ lỗi 413 Request Entity Too Large xảy ra hoặc
    • Nếu bạn có thể tái tạo vấn đề, hãy thực hiện lệnh gọi API và tái tạo lỗi 413 Request Entity Too Large

  2. Đảm bảo bạn đã bật chế độ Show all Flow Infos (Hiện tất cả thông tin về luồng).

  3. Chọn một trong các yêu cầu không thực hiện được và kiểm tra dấu vết.
  4. Chuyển đến giai đoạn Yêu cầu nhận được từ khách hàng.

    Không nén

    Trường hợp 1: Tải trọng yêu cầu được gửi ở dạng chưa nén

    Xin lưu ý những thông tin sau:

    • Không có Content-Encoding
    • Content-Length: 15360204

    Đã nén

    Tình huống 2: Tải trọng yêu cầu được gửi ở dạng nén

    Xin lưu ý những thông tin sau:

    • Content-Encoding: gzip
    • Content-Length: 14969
    • Content-Type: application/x-gzip
  5. Điều hướng qua các giai đoạn khác nhau của dấu vết và xác định vị trí xảy ra lỗi.

  6. Bạn thường sẽ thấy lỗi này trong một luồng sau giai đoạn Đã nhận được yêu cầu từ khách hàng như minh hoạ dưới đây:

  7. Lưu ý giá trị của lỗi trong dấu vết. Dấu vết mẫu ở trên cho thấy:
    • error: Body buffer overflow
    • error.class: com.apigee.errors.http.user.RequestTooLarge

  8. Chuyển đến Response Sent to Client (Phản hồi đã gửi đến ứng dụng) và ghi lại các giá trị của lỗi trong dấu vết. Dấu vết mẫu bên dưới cho thấy:

    • error: 413 Request Entity Too Large
    • Nội dung lỗi: {"fault":{"faultstring":"Body buffer overflow","detail":{"errorcode":"protocol.http.TooBigBody"}}}
  9. Chuyển đến Giai đoạn AX (Dữ liệu Analytics được ghi lại) trong dấu vết rồi nhấp vào giai đoạn đó.

  10. Trong phần Phase Details (Thông tin chi tiết về giai đoạn), hãy di chuyển xuống phần Variables Read (Các biến được đọc).

  11. Xác định giá trị của biến client.received.content.length . Biến này cho biết:
    • Kích thước thực tế của tải trọng yêu cầu khi được gửi ở định dạng chưa nén và
    • Kích thước của tải trọng yêu cầu sau khi giải nén bằng Apigee, khi tải trọng được gửi ở định dạng nén. Trong trường hợp này, kích thước này sẽ luôn bằng với giá trị của hạn mức cho phép (10 MB).

    Không nén

    Trường hợp 1: Tải trọng yêu cầu ở dạng chưa nén

    biến client.received.content.length: 15360204

    Đã nén

    Tình huống 2: Yêu cầu tải trọng ở định dạng nén

    biến client.received.content.length: 10489856

  12. Bảng sau đây giải thích lý do Apigee trả về lỗi 413 trong 2 trường hợp dựa trên giá trị của biến client.received.content.length:
    Trường hợp Giá trị của client.received.content.length Lý do xảy ra lỗi
    Tải trọng của yêu cầu ở định dạng chưa nén ~15 MB Kích thước > giới hạn cho phép là 10 MB.
    Tải trọng của yêu cầu ở định dạng nén ~10 MB

    Đã vượt quá giới hạn kích thước khi giải nén

NGINX

Cách chẩn đoán lỗi bằng nhật ký truy cập NGINX:

  1. Nếu là người dùng Đám mây riêng, thì bạn có thể sử dụng nhật ký truy cập NGINX để xác định thông tin chính về lỗi HTTP 413.

  2. Kiểm tra nhật ký truy cập NGINX:

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

  3. Tìm kiếm để xem có lỗi 413 nào xảy ra trong một khoảng thời gian cụ thể hay không (nếu vấn đề xảy ra trong quá khứ) hoặc xem có yêu cầu nào vẫn không thành công với 413 hay không.
  4. Nếu bạn tìm thấy bất kỳ lỗi 413 nào có X-Apigee-fault-code khớp với giá trị của protocol.http.TooBigBody, thì hãy xác định giá trị của X-Apigee-fault-source.

    Không nén

    Trường hợp 1 : Kích thước tải trọng yêu cầu ở định dạng chưa nén

    Mục nhập mẫu ở trên trong nhật ký truy cập NGINX có các giá trị sau cho X-Apigee-fault-code và X-Apigee-fault-source:

    Tiêu đề phản hồi Giá trị
    X-Apigee-fault-code protocol.http.TooBigBody
    X-Apigee-fault-sourc policy

    Lưu ý Độ dài yêu cầu: 15360440 (14,6 MB > giới hạn cho phép)

    Đã nén

    Trường hợp 2 : Kích thước tải trọng yêu cầu ở định dạng nén

    Mục nhập mẫu ở trên trong nhật ký truy cập NGINX có các giá trị sau cho X-Apigee-fault-code và X-Apigee-fault-source:

    Tiêu đề phản hồi Giá trị
    X-Apigee-fault-code protocol.http.TooBigBody
    X-Apigee-fault-source policy

    Lưu ý Độ dài yêu cầu: 15264 (14,9 K < giới hạn cho phép)

    Trong trường hợp này, Apigee Edge trả về 413 mặc dù Request Length (Độ dài yêu cầu) thấp hơn giới hạn cho phép vì yêu cầu có thể đã được gửi ở định dạng nén và kích thước của tải trọng vượt quá giới hạn khi Apigee Edge giải nén.

Nguyên nhân: Kích thước tải trọng yêu cầu lớn hơn giới hạn cho phép

Chẩn đoán

  1. Xác định Mã lỗi, Nguồn lỗi và Kích thước tải trọng yêu cầu cho lỗi quan sát được bằng cách sử dụng tính năng Giám sát API, Công cụ theo dõi hoặc nhật ký truy cập NGINX như được giải thích trong Các bước chẩn đoán thường gặp với Tình huống 1 (chưa nén).
  2. Nếu Nguồn lỗi có giá trị là policy hoặc proxy, thì điều này cho biết kích thước tải trọng yêu cầu do ứng dụng khách gửi đến Apigee lớn hơn giới hạn cho phép trong Apigee Edge.
  3. Xác minh Kích thước trọng tải yêu cầu như được xác định ở bước 1.
  4. Bạn cũng có thể xác thực xem kích thước tải trọng của yêu cầu có thực sự vượt quá giới hạn cho phép là 10 MB hay không bằng cách kiểm tra yêu cầu thực tế theo các bước sau:
    1. Nếu bạn không có quyền truy cập vào yêu cầu thực tế do ứng dụng khách đưa ra, hãy chuyển đến phần Giải pháp.
    2. Nếu bạn có quyền truy cập vào yêu cầu thực tế do ứng dụng khách đưa ra, hãy thực hiện các bước sau:
      1. Xác minh kích thước của tải trọng được truyền trong yêu cầu.
      2. Nếu bạn nhận thấy kích thước của tải trọng lớn hơn giới hạn cho phép trong Apigee Edge, thì đó là nguyên nhân gây ra vấn đề.

        3. Yêu cầu mẫu:

        curl http://<hostalias>/testtoobigbody -k -X POST -F file=@test15mbfile -v

        Trong trường hợp trên, tệp test15mbfile có kích thước khoảng 15 MB. Nếu bạn đang sử dụng một ứng dụng khác, hãy lấy nhật ký ứng dụng để biết kích thước tải trọng đang được gửi.

Độ phân giải

Chuyển đến phần Độ phân giải.

Nguyên nhân: Kích thước tải trọng yêu cầu vượt quá giới hạn cho phép sau khi giải nén

Nếu tải trọng yêu cầu được gửi ở định dạng nén và tiêu đề của yêu cầu Content-Encoding được đặt thành gzip, , thì Apigee sẽ giải nén tải trọng yêu cầu. Trong quá trình giải nén, nếu Apigee nhận thấy kích thước tải trọng lớn hơn 10 MB, giới hạn cho phép, thì quá trình giải nén sẽ dừng lại và ngay lập tức phản hồi bằng 413 Request Entity Too Large kèm theo mã lỗi protocol.http.TooBigBody.

Chẩn đoán

  1. Xác định Mã lỗi, Nguồn lỗi và kích thước Tải trọng yêu cầu cho lỗi quan sát được bằng cách sử dụng tính năng Giám sát API, Công cụ theo dõi hoặc nhật ký truy cập NGINX như được giải thích trong Các bước chẩn đoán thường gặp với Tình huống 2 (được nén).
  2. Nếu Nguồn lỗi có giá trị policy hoặc proxy, thì điều này cho biết kích thước tải trọng yêu cầu do ứng dụng khách gửi đến Apigee lớn hơn giới hạn cho phép trong Apigee Edge.
  3. Xác minh Kích thước trọng tải yêu cầu như được xác định trong bước 1.
    • Nếu kích thước tải trọng lớn hơn giới hạn cho phép là 10 MB, thì đó là nguyên nhân gây ra lỗi.
    • Nếu kích thước tải trọng < 10 MB (giới hạn cho phép), thì có thể tải trọng yêu cầu được truyền ở định dạng nén. Trong trường hợp này, hãy kiểm tra kích thước chưa nén của tải trọng yêu cầu được nén.
  4. Bạn có thể xác thực xem yêu cầu từ ứng dụng khách có được gửi ở định dạng nén hay không và kích thước chưa nén lớn hơn giới hạn cho phép bằng một trong các phương thức sau:

    Trace

    Cách xác thực bằng công cụ Trace:

    1. Nếu bạn đã ghi lại dấu vết cho yêu cầu không thành công, hãy tham khảo các bước được trình bày chi tiết trong phần Dấu vết và
      1. Xác định giá trị của biến client.received.content.length
      2. Xác minh xem yêu cầu từ máy khách có chứa tiêu đề Content-Encoding: gzip hay không
    2. Nếu giá trị của biến client.received.content.length lớn hơn 10 MB, giới hạn cho phép và tiêu đề của yêu cầu Content-Encoding: gzip, thì đó là nguyên nhân gây ra lỗi này.

    Yêu cầu thực tế

    Cách xác thực bằng yêu cầu thực tế:

    1. Nếu bạn không có quyền truy cập vào yêu cầu thực tế do ứng dụng khách đưa ra, hãy chuyển đến phần Giải pháp.
    2. Nếu bạn có quyền truy cập vào yêu cầu thực tế do ứng dụng khách đưa ra, hãy thực hiện các bước sau:
      1. Xác minh kích thước của tải trọng được truyền trong yêu cầu cùng với tiêu đề Content-Encoding được gửi trong yêu cầu.

      2. Kiểm tra xem kích thước chưa nén của tải trọng có lớn hơn giới hạn cho phép trong Apigee Edge hay không

        Yêu cầu mẫu:

        curl https://<hostalias>/testtoobigbody -k -X POST -F file=@test15mbfile.gz -H "Content-Encoding: gzip" -v

        Trong trường hợp trên, tệp test15mbfile.gz có kích thước nhỏ hơn giới hạn; tuy nhiên, kích thước của tệp chưa nén test15mbfile là khoảng 15 MB và tiêu đề Content-Encoding là gzip.

        Nếu bạn đang sử dụng một ứng dụng khác, hãy lấy nhật ký ứng dụng để tìm hiểu kích thước tải trọng đang được gửi và liệu tiêu đề Content-Encoding có được đặt thành gzip hay không.

    Nhật ký Trình xử lý tin nhắn

    Cách xác thực bằng nhật ký Message Processor:

    1. Nếu là người dùng Đám mây riêng, bạn có thể sử dụng nhật ký Trình xử lý thông báo để xác định thông tin chính về lỗi HTTP 413.

    2. Kiểm tra nhật ký của Trình xử lý thư:

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

    3. Tìm kiếm để xem có lỗi 413 nào xảy ra trong một khoảng thời gian cụ thể hay không (nếu vấn đề xảy ra trong quá khứ) hoặc xem có yêu cầu nào vẫn gặp lỗi 413 hay không.

      Bạn có thể sử dụng các chuỗi tìm kiếm sau:

      grep -ri "chunkCount"

      grep -ri "RequestTooLarge"
    4. Bạn sẽ thấy các dòng từ system.log tương tự như sau (TotalRead và chunkCount có thể khác nhau trong trường hợp của bạn): 
      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. Trong quá trình giải nén, ngay khi Message Processor xác định tổng số byte đã đọc là > 10 MB, nó sẽ dừng và in dòng sau: 
      Message is too large.  TotalRead 10489856 chunkCount 2570

      Điều này có nghĩa là Kích thước tải trọng yêu cầu lớn hơn 10 MB và Apigee sẽ đưa ra lỗi RequestTooLarge khi kích thước bắt đầu vượt quá giới hạn 10 MB với mã lỗi là protocol.http.TooBigBody

Độ phân giải

Kích thước cố định

Lựa chọn 1 [Đề xuất]: Sửa ứng dụng khách để không gửi kích thước tải trọng lớn hơn giới hạn cho phép

  1. Phân tích lý do khiến máy khách cụ thể gửi yêu cầu / kích thước tải trọng vượt quá giới hạn cho phép như được xác định trong phần Giới hạn.

  2. Nếu không mong muốn, hãy sửa đổi ứng dụng khách của bạn để ứng dụng gửi yêu cầu / kích thước tải trọng nhỏ hơn giới hạn cho phép.

    Trong ví dụ được thảo luận ở trên, bạn có thể khắc phục vấn đề bằng cách truyền một tệp có kích thước nhỏ hơn, giả sử tải trọng test5mbfile (có kích thước là 5 MB) như minh hoạ dưới đây: 

    curl https://<host>/testtoobigbody -k -X POST -F file=@test5mbfile -v
  3. Nếu bạn muốn gửi yêu cầu/tải trọng vượt quá giới hạn cho phép, hãy chuyển sang các lựa chọn tiếp theo.

Mẫu URL đã ký

Lựa chọn 2 [Nên dùng]: Sử dụng mẫu URL đã ký trong Apigee JavaCallout

Đối với tải trọng lớn hơn 10 MB, Apigee đề xuất sử dụng mẫu URL đã ký trong Apigee JavaCallout, minh hoạ bằng ví dụ Edge Callout: Signed URL Generator trên GitHub.

Phát trực tiếp

Cách 3 : Sử dụng tính năng phát trực tuyến

Nếu proxy API của bạn cần xử lý các yêu cầu và/hoặc phản hồi có kích thước rất lớn, thì bạn có thể bật tính năng truyền phát trực tuyến trong Apigee.

CwC

Cách 4 : Sử dụng thuộc tính CwC để tăng giới hạn vùng đệm

Bạn chỉ nên sử dụng lựa chọn này khi không thể sử dụng bất kỳ lựa chọn nào được đề xuất vì có thể xảy ra các vấn đề về hiệu suất nếu kích thước mặc định tăng lên.

Apigee cung cấp một thuộc tính CwC cho phép tăng giới hạn kích thước tải trọng của yêu cầu và phản hồi. Để biết thông tin chi tiết, hãy tham khảo phần Đặt giới hạn kích thước thư trên Bộ định tuyến hoặc Trình xử lý thư

Giới hạn

Apigee yêu cầu ứng dụng khách và máy chủ phụ trợ không gửi kích thước tải trọng lớn hơn giới hạn cho phép như được ghi lại cho Request/response size trong Giới hạn của Apigee Edge.

  1. Nếu là người dùng Đám mây công cộng, thì giới hạn tối đa cho kích thước tải trọng của yêu cầu và phản hồi sẽ như được ghi lại cho Request/response size trong Giới hạn của Apigee Edge.
  2. Nếu là người dùng Đám mây riêng tư , thì bạn có thể đã sửa đổi giới hạn mặc định cho kích thước tải trọng yêu cầu và phản hồi (mặc dù đây không phải là cách nên làm). Bạn có thể xác định giới hạn kích thước tải trọng tối đa của yêu cầu bằng cách làm theo hướng dẫn trong phần Cách kiểm tra giới hạn hiện tại.

Cách kiểm tra hạn mức hiện tại

Phần này giải thích cách xác minh rằng thuộc tính HTTPRequest.body.buffer.limit đã được cập nhật bằng một giá trị mới trên Message Processors.

  1. Trên máy Xử lý thông báo, hãy tìm thuộc tính HTTPRequest.body.buffer.limit trong thư mục /opt/apigee/edge-message- processor/conf và kiểm tra xem giá trị nào đã được đặt bằng lệnh sau: 
    grep -ri "HTTPRequest.body.buffer.limit" /opt/apigee/edge-message-processor/conf
  2. Sau đây là kết quả mẫu của lệnh trên: 
    /opt/apigee/edge-message-processor/conf/http.properties:HTTPRequest.body.buffer.limit=10m

  3. Trong đầu ra mẫu ở trên, hãy lưu ý rằng thuộc tính HTTPRequest.body.buffer.limit đã được đặt với giá trị 10m trong http.properties.

    Điều này cho thấy giới hạn kích thước tải trọng yêu cầu được định cấu hình trong Apigee cho Private Cloud là 10 MB.

Nếu bạn vẫn cần được Nhóm hỗ trợ Apigee trợ giúp, hãy truy cập vào phần Thông tin chẩn đoán bắt buộc phải thu thập.

Phải thu thập thông tin chẩn đoán

Thu thập thông tin chẩn đoán sau đây, rồi liên hệ với Nhóm hỗ trợ Apigee Edge:

Nếu bạn là người dùng Đám mây công cộng, hãy cung cấp những thông tin sau:

  • Tên tổ chức
  • Tên môi trường
  • Tên API Proxy
  • Lệnh curl hoàn chỉnh dùng để tái tạo lỗi 413
  • Tệp theo dõi cho các yêu cầu API

Nếu bạn là người dùng Đám mây riêng, hãy cung cấp những thông tin sau:

  • Thông báo lỗi hoàn chỉnh được ghi nhận cho các yêu cầu không thành công
  • Tên tổ chức
  • Tên môi trường
  • Gói API Proxy
  • Tệp theo dõi cho các yêu cầu API không thành công
  • Lệnh curl hoàn chỉnh dùng để tái tạo lỗi 413

  • Nhật ký truy cập NGINX /opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log

    Trong đó: ORG, ENV và PORT# được thay thế bằng các giá trị thực tế.

  • Nhật ký hệ thống của Trình xử lý tin nhắn /opt/apigee/var/log/edge-message-processor/logs/system.log