502 Bad Gateway - ResponseWithBody

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 502 Bad Gateway với mã lỗi protocol.http.ResponseWithBody 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 502 Bad Gateway

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

{
   "fault":{
      "faultstring":"Received 204 Response with message body",
      "detail":{
         "errorcode":"protocol.http.ResponseWithBody"
      }
   }
}

{
   "fault":{
      "faultstring":"Received 205 Response with message body",
      "detail":{
         "errorcode":"protocol.http.ResponseWithBody"
      }
   }
}

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

Lỗi này xảy ra nếu phản hồi HTTP từ máy chủ phụ trợ đến Apigee Edge là 204 No Content hoặc 205 Reset Content nhưng chứa nội dung phản hồi và/hoặc một hoặc nhiều tiêu đề sau:

• Content-Length
• Content-Encoding
• Transfer-Encoding

Theo quy cách RFC 7231, phần 6.3.5: 204 Không có nội dung và RFC 7231, phần 6.3.6: 205 Đặt lại nội dung, máy chủ gốc không được gửi thêm nội dung nào trong phần nội dung hữu ích của phản hồi có mã trạng thái 204 No Content hoặc 205 Reset Content. Các tiêu đề phản hồi như Content-Length, Content-Encoding hoặc Transfer-Encoding cho biết kích thước, loại hoặc định dạng của tải trọng phản hồi.

Do đó, Apigee Edge sẽ trả về mã trạng thái 502 Bad Gateway kèm theo mã lỗi protocol.http.ResponseWithBody cho ứng dụng khách trong các trường hợp sau:

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

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:

Nguyên nhân: Nội dung phản hồi hoặc tiêu đề có phản hồi 204 từ máy chủ phụ trợ

Chẩn đoán

1. Xác định Mã lỗi và Nguồn lỗi 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 phần Các bước chẩn đoán thường gặp.
2. Nếu Mã lỗi là protocol.http.ResponseWithBody và Nguồn lỗi có giá trị là target, thì điều này cho biết máy chủ phụ trợ đã phản hồi bằng mã trạng thái 204 No Content hoặc 205 Reset Content cùng với nội dung phản hồi và/hoặc một trong các tiêu đề được đề cập trong phần Nguyên nhân có thể xảy ra.

3. Để xác thực xem máy chủ phụ trợ có thực sự gửi nội dung tải trọng phản hồi và/hoặc một hoặc nhiều tiêu đề được đề cập trong phần Các nguyên nhân có thể xảy ra hay không, bạn có thể thực hiện các bước sau:

   1. Nếu bạn là người dùng Đám mây công khai và nếu bạn có thể gửi cùng một yêu cầu API đến máy chủ phụ trợ ngay từ bất kỳ hệ thống nào của mình.

   2. Nếu là người dùng Đám mây riêng, thì bạn có thể đưa ra cùng một yêu cầu API cho máy chủ phụ trợ ngay từ một trong các Trình xử lý thông báo được liên kết với tổ chức và môi trường cụ thể nơi xảy ra lỗi.

   3. Xem xét phản hồi nhận được từ máy chủ phụ trợ và xác minh rằng phản hồi đó chứa nội dung tải trọng phản hồi và/hoặc một hoặc nhiều phần đầu được đề cập ở trên. Nếu có, thì đó là nguyên nhân gây ra lỗi này.

      Mẫu số 1

      Ví dụ 1: Phản hồi của máy chủ phụ trợ 204 có tiêu đề Content-Encoding

      curl -v "https://BACKEND_SERVER_HOST_NAME/PATH" -H "HEADER: VALUE" -X HTTP_REQUEST_METHOD
      

      …
      < HTTP/1.1 204 No Content
      < Content-Encoding: gzip
      < Date: Tue, 31 Jul 2021 21:41:13 GMT
      < Connection: keep-alive
      

      Trong mẫu này, máy chủ phụ trợ đã phản hồi bằng mã trạng thái 204 No Content và Content-Encoding: gzip

      Mẫu số 2

      Ví dụ 2: Phản hồi của máy chủ phụ trợ 204 có tiêu đề Content-Length

      curl -v "https://BACKEND_SERVER_HOST_NAME/PATH" -H "HEADER: VALUE" -X HTTP_REQUEST_METHOD
      

      …
      < HTTP/1.1 204 No Content
      < Content-Length: 48
      < Date: Tue, 31 Jul 2021 21:41:13 GMT
      < Connection: keep-alive
      

      Trong mẫu này, máy chủ phụ trợ đã phản hồi bằng mã trạng thái 204 No Content và Content-Length: 48

      Ví dụ 3

      Ví dụ 3: Phản hồi của máy chủ phụ trợ 205 có nội dung phản hồi

      curl -v "https://BACKEND_SERVER_HOST_NAME/PATH" -H "HEADER: VALUE" -X HTTP_REQUEST_METHOD
      

      …
      < HTTP/1.1 205 Reset Content
      < Date: Sat, 31 Jul 2021 17:14:09 GMT
      < Content-Length: 12
      < Content-Type: text/plain; charset=utf-8
      <
      * Connection #0 to host X.X.X.X left intact
      This is a sample Response
      

      Trong mẫu này, máy chủ phụ trợ đã phản hồi bằng mã trạng thái 205 Reset Content kèm theo nội dung phản hồi This is a sample Response.

   4. Trong tất cả các ví dụ trên, máy chủ phụ trợ đã gửi mã trạng thái 204 No Content hoặc 205 Reset Content cùng với nội dung phản hồi và/hoặc một trong các tiêu đề được đề cập trong phần Các nguyên nhân có thể xảy ra.
   5. Do đó, Apigee Edge đã gửi mã trạng thái 502 Bad Gateway kèm theo mã lỗi protocol.http.ResponseWithBody.

Độ phân giải

Đảm bảo rằng máy chủ phụ trợ luôn tuân thủ Quy cách RFC 7231, phần 6.3.6: 205 Đặt lại nội dung khi gửi phản hồi 204 No Content hoặc 205 Reset Content đến Apigee Edge. Tức là máy chủ phụ trợ KHÔNG ĐƯỢC gửi nội dung sau đây trong phản hồi 204 No Content hoặc 205 Reset Content:

1. Nội dung phản hồi
2. Và bất kỳ tiêu đề nào sau đây:
   1. Content-Length
   2. Content-Encoding
   3. Transfer-Encoding

Thông số kỹ thuật

Apigee Edge phản hồi bằng mã trạng thái 502 Bad Gateway và mã lỗi protocol.http.ResponseWithBody nếu máy chủ phụ trợ gửi phản hồi 204 No Content hoặc 205 Reset Content nhưng không tuân thủ các quy cách RFC sau:

Những điểm chính cần lưu ý

Giải pháp được đề xuất là sửa máy chủ phụ trợ để gửi mã trạng thái 204 No Content và 205 Reset Content mà không có nội dung phản hồi và bất kỳ tiêu đề nào – Content-Length, Content-Encoding và Transfer-Encoding, đồng thời tuân thủ các quy cách RFC 7231, phần 6.3.5: 204 Không có nội dung và RFC 7231, phần 6.3.6: 205 Đặt lại nội dung.

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 tất được dùng để tái tạo lỗi 502
• 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 môi trường
• Gói API Proxy
• Tệp theo dõi cho các yêu cầu API

• 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