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

Bạn đang xem tài liệu về Apigee Edge.
Chuyển đến Tài liệu về Apigee X. thông tin

Triệu chứng

Ứng dụng khách sẽ 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 lệnh gọi API.

Thông báo Lỗi

Ứng dụng sẽ nhận được mã phản hồi sau đây: 

HTTP/1.1 413 Request Entity Too Large

Ngoài ra, bạn có thể nhận 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 gửi đến Apigee Edge như một phần của Yêu cầu HTTP lớn hơn giới hạn được phép trong Apigee Edge .

Dưới đây là các 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 mà ứng dụng gửi trong yêu cầu HTTP đến Apigee Edge là vượt quá giới hạn cho phép trong Apigee Edge. Người dùng Edge công khai và riêng tư
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 gửi ở định dạng nén như một phần của HTTP yêu cầu đối với Apigee Edge vượt quá giới hạn cho phép khi giải nén bằng Apigee Edge. Người dùng Edge công khai và riêng tư

Các bước chẩn đoán phổ biến

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ò thích hợp.

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

  3. Chuyển đến thẻ Analyze (Phân tích) > Giám sát API > Điều tra.
  4. Chọn khung thời gian cụ thể mà bạn phát hiện thấy lỗi.
  5. Bạn có thể chọn bộ lọc Proxy để thu hẹp 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 413như minh hoạ dưới đây:

  8. Thông tin về mã lỗi protocol.http.TooBigBody được hiển thị dưới dạng được hiển thị bên dưới:

  9. Nhấp vào Xem nhật ký và mở rộng hàng của yêu cầu không thành công. Sau đó, từ Trong cửa sổ Nhật ký, hãy lưu ý thông tin chi tiết như sau :

    Đã giải nén

    Tình huống 1: Yêu cầu tải trọng được gửi ở dạng không nén

    Từ cửa sổ Nhật ký, hãy lưu ý những thông tin chi tiết 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 , thì Mã lỗi có giá trị protocol.http.TooBigBody và Request Duration (Thời lượng yêu cầu) lớn hơn 10 MB, thì nó cho biết rằng yêu cầu HTTP từ máy khách có yêu cầu kích thước tải trọng lớn hơn giới hạn cho phép trong Apigee.

    Đã nén

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

    Từ cửa sổ Logs (Nhật ký), hãy lưu ý những thông tin chi tiết 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 (~15kB)

    Nếu Nguồn lỗi có giá trị proxy , thì Mã lỗi có giá trị protocol.http.TooBigBody và Request Duration (Thời lượng yêu cầu) là nhỏ hơn 10 MB, thì nó cho biết rằng yêu cầu HTTP từ máy khách có kích thước tải trọng yêu cầu thấp 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 không được nén bằng Apigee.

Trace

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

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

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

  3. Chọn một trong các yêu cầu không thành công rồi kiểm tra dấu vết.
  4. Chuyển đến giai đoạn Đã nhận yêu cầu từ ứng dụng.

    Đã giải nén

    Tình huống 1: Yêu cầu tải trọng được gửi ở dạng không nén

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

    • Content-Encoding: không có
    • Thời lượng nội dung: 15360204

    Đã nén

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

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

    • Mã hoá nội dung: gzip
    • Thời lượng nội dung: 14969
    • Loại nội dung: application/x-gzip
  5. Di chuyển qua các giai đoạn của quá trình theo dõi và xác định nơi xảy ra lỗi.

  6. Thông thường, bạn sẽ gặp lỗi này trong luồng sau Yêu cầu đã nhận được từ Giai đoạn khách hàng như sau:

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

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

    • lỗi: 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 (Đã ghi dữ liệu Analytics) trong dấu vết và nhấp vào đó.

  10. Trong phần Thông tin chi tiết về giai đoạn, hãy di chuyển xuống phần Đọc các biến.

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

    Đã giải nén

    Tình huống 1: Yêu cầu tải trọng ở dạng không nén

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

    Đã nén

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

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

  12. Bảng sau đây giải thích lý do tại sao lỗi 413 được Apigee trả về trong hai 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 không đạt
    Yêu cầu tải trọng ở định dạng không nén Khoảng 15 MB Kích thước > tối đa là 10 MB.
    Yêu cầu tải trọng ở đị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 tư, bạn có thể sử dụng nhật ký truy cập NGINX để xác định thông tin quan trọng 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 trong một khoảng thời gian cụ thể không (nếu sự cố đã xảy ra trong quá khứ) hoặc nếu vẫn không thành công với bất kỳ yêu cầu nào 413.
  4. Nếu bạn tìm thấy lỗi 413 khi so khớp X-Apigee-fault-code giá trị của protocol.http.TooBigBody, sau đó xác định giá trị của X-Apigee-fault-source.

    Đã giải nén

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

    Mục nhập mẫu ở trên từ 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

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

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

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

    Lưu ý Thời lượng 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ù Thời lượng 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á khi giải nén bằng Apigee Edge.

Nguyên nhân: Yêu cầu Kích thước tải trọng 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 phát hiện được khi sử dụng nhật ký Giám sát API, Công cụ theo dõi hoặc NGINX truy cập như được giải thích trong Các bước chẩn đoán phổ biến trong Tình huống 1 (không nén).
  2. Nếu Nguồn lỗi có giá trị policy hoặc proxy, thì phương thức này cho biết kích thước tải trọng yêu cầu mà ứng dụng gửi đến Apigee lớn hơn giới hạn được phép trong Apigee Edge.
  3. Xác minh Yêu cầu kích thước tải trọng như đã xác định trong bước 1.
  4. Bạn cũng có thể xác thực xem kích thước tải trọng yêu cầu có thực sự > hay không Giới hạn cho phép là 10 MB kiểm tra yêu cầu thực tế bằng cách làm 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 đưa ra, hãy chuyển đến Độ phân giải.
    2. Nếu bạn có quyền truy cập vào yêu cầu thực tế do ứng dụng đư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 thấy rằng 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 là ~15 MB. Nếu bạn đang dùng một số ứng dụng khách khác, hãy lấy nhật ký ứng dụng khách để tìm hiểu kích thước tải trọng đang được gửi.

Độ phân giải

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

Nguyên nhân: Yêu cầu Kích thước tải trọng 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 đề yêu cầu Content-Encoding được đặt thành gzip, Apigee sẽ giải nén yêu cầu tải trọng. Trong quá trình giải nén, nếu Apigee thấy kích thước của tải trọng lớn hơn trên 10 MB, giới hạn cho phép, thì hệ thống sẽ ngừng giải nén thêm và phản hồi lại ngay lập tức với 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 đối với lỗi quan sát được khi sử dụng nhật ký Giám sát API, Công cụ theo dõi hoặc NGINX Access như giải thích trong Các bước chẩn đoán phổ biến trong 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 thấy kích thước tải trọng yêu cầu do ứng dụng gửi đến Apigee lớn hơn vượt quá giới hạn cho phép trong Apigee Edge.
  3. Xác minh Yêu cầu kích thước tải trọng như đã xác định trong bước 1.
    • Nếu kích thước tải trọng > 10 MB cho phép, thì đó là nguyên nhân gây ra lỗi.
    • Nếu kích thước tải trọng < giới hạn cho phép là 10 MB, thì có khả năng yêu cầu tải trọng đượ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 có được gửi ở định dạng nén và kích thước không nén lớn hơn giới hạn cho phép bằng một trong các giá trị sau phương thức:

    Trace

    Cách xác thực bằng công cụ Theo dõi:

    1. Nếu bạn đã thu thập được 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 nêu chi tiết trong Trace 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ừ ứng dụng có chứa Content-Encoding: gzip tiêu đề
    2. Nếu giá trị của biến client.received.content.length lớn hơn 10 MB, giới hạn được phép và tiêu đề 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 đưa ra, hãy chuyển đến Độ phân giải.
    2. Nếu bạn có quyền truy cập vào yêu cầu thực tế do ứng dụng đư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 Content-Encoding tiêu đề được gửi trong yêu cầu.

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

        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 nhỏ hơn giới hạn kích thước; tuy nhiên, kích thước của tệp không nén test15mbfile là ~15 MB và tiêu đề Content-Encoding là gzip.

        Nếu bạn đang dùng một số ứ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à nếu tiêu đề Content-Encoding được đặt thành gzip.

    Nhật ký Trình xử lý thư

    Để xác thực bằng nhật ký Trình xử lý thư:

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

    2. Kiểm tra nhật ký 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 trong một khoảng thời gian cụ thể hay không (nếu sự cố nào đã xảy ra trong quá khứ) hoặc nếu có bất kỳ yêu cầu nào vẫn không thành công với 413.

      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 tuyến từ system.log tương tự như sau (TotalRead và chunkCount có thể thay đổi 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 Bộ xử lý thư xác định tổng số byte đọc là > 10 MB, thiết bị 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 của yêu cầu lớn hơn 10 MB và sẽ gửi Apigee lỗi RequestTooLarge khi kích thước bắt đầu vượt quá giới hạn 10 MB có mã lỗi là protocol.http.TooBigBody

Độ phân giải

Khắc phục kích thước

Phương án 1 [Nên dùng]: Khắc phục lỗi ứng dụng 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 ứng dụng cụ thể gửi yêu cầu / kích thước tải trọng nhiều hơn mức cho phép như được xác định trong Giới hạn.

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

    Trong ví dụ đã thảo luận ở trên, bạn có thể khắc phục vấn đề này bằng cách chuyể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 đó là mong muốn và bạn muốn gửi yêu cầu/tải trọng lớn hơn giới hạn cho phép, hãy chuyển đến các tuỳ chọn tiếp theo.

Mẫu URL đã ký

Tuỳ chọn 2 [Nên dùng]: Sử dụng mẫu URL đã ký trong Apigee JavaAnnotation

Đối với các tải trọng lớn hơn 10 MB, Apigee khuyên bạn nên sử dụng mẫu URL đã ký trong Chú thích Java trong Apigee, được minh hoạ bằng Ví dụ về chú thích cạnh: Trình tạo URL đã ký trên GitHub.

Phát trực tiếp

Lựa chọn 3 : Sử dụng tính năng phát trực tiếp

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 rất lớn, bạn có thể bật phát trực tuyến trong Apigee.

CwC

Lựa chọn 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 tuỳ chọn này khi không thể sử dụng bất kỳ tuỳ chọn được đề xuất nào vì có thể là 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 CwC, giú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 Đặ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 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 trong tài liệu của Request/response size trong Giới hạn Apigee Edge.

  1. Nếu bạn là người dùng Cloud Public, thì giới hạn tối đa đối với yêu cầu và phản hồi kích thước tải trọng được ghi lại cho Request/response size trong Giới hạn Apigee Edge.
  2. Nếu là người dùng Đám mây riêng tư , thì có thể bạn đã sửa đổi chế độ mặc định giới hạn cho kích thước tải trọng của yêu cầu và phản hồi (mặc dù đây không phải là phương pháp được đề xuất). 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 Cách kiểm tra hạn mức 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 một giá trị mới trên Trình xử lý thư.

  1. Trên máy Xử lý thư, hãy tìm kiế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 cách sử dụng : 
    grep -ri "HTTPRequest.body.buffer.limit" /opt/apigee/edge-message-processor/conf
  2. Kết quả mẫu từ lệnh trên như sau: 
    /opt/apigee/edge-message-processor/conf/http.properties:HTTPRequest.body.buffer.limit=10m

  3. Trong kết quả của ví dụ ở trên, hãy lưu ý rằng thuộc tính Đã đặt HTTPRequest.body.buffer.limit với giá trị 10m trong http.properties.

    Mã này cho biết giới hạn về kích thước tải trọng yêu cầu được định cấu hình trong Apigee cho Riêng tư Đám mây có kích thước 10 MB.

Nếu bạn vẫn cần hỗ trợ từ Nhóm hỗ trợ Apigee, hãy truy cập vào Phải thu thập thông tin chẩn đoán.

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

Thu thập những thông tin chẩn đoán sau đây rồi liên hệ với Bộ phận hỗ trợ Apigee Edge:

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

  • Tên tổ chức
  • Tên môi trường
  • Tên proxy API
  • Hoàn tất lệnh curl dùng để tái hiện 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 tư, hãy cung cấp các thông tin sau:

  • Đã nhận thấy thông báo lỗi hoàn chỉnh đối với các yêu cầu không thực hiện được
  • Tên tổ chức
  • Tên môi trường
  • Gói Proxy API
  • Tệp theo dõi cho các yêu cầu API không thành công
  • Hoàn tất lệnh curl dùng để tái hiện lỗi 413

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

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

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