502 Bad Gateway - ResponseWithBody

شما در حال مشاهده مستندات Apigee Edge هستید.
به مستندات Apigee X مراجعه کنید . اطلاعات

علامت

برنامه‌ی کلاینت، کد وضعیت HTTP معادل 502 Bad Gateway را به همراه کد خطای protocol.http.ResponseWithBody به عنوان پاسخی برای فراخوانی‌های API دریافت می‌کند.

پیام خطا

برنامه‌ی کلاینت کد پاسخ زیر را دریافت می‌کند:

HTTP/1.1 502 Bad Gateway

علاوه بر این، ممکن است یکی از پیام‌های خطای زیر را مشاهده کنید:

{
   "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"
      }
   }
}

علل احتمالی

این خطا زمانی رخ می‌دهد که پاسخ HTTP از سرور backend به Apigee Edge یا 204 No Content یا 205 Reset Content باشد، اما شامل بدنه پاسخ و/یا یک یا چند مورد از هدرهای زیر باشد:

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

طبق مشخصات RFC 7231، بخش 6.3.5: 204 No Content و RFC 7231، بخش 6.3.6: 205 Reset Content ، انتظار می‌رود که هیچ محتوای اضافی به عنوان بخشی از بدنه‌ی payload پاسخ با کد وضعیت 204 No Content یا 205 Reset Content توسط سرور مبدا ارسال نشود. هدرهای پاسخ مانند Content-Length ، Content-Encoding یا Transfer-Encoding اندازه، نوع یا قالب payload پاسخ را نشان می‌دهند.

بنابراین، Apigee Edge تحت شرایط زیر کد وضعیت 502 Bad Gateway را با کد خطای protocol.http.ResponseWithBody به کلاینت برمی‌گرداند:

در اینجا علل احتمالی این خطا آورده شده است:

مراحل تشخیص مشترک

برای تشخیص این خطا از یکی از ابزارها/تکنیک‌های زیر استفاده کنید:

علت: بدنه پاسخ یا هدرها با پاسخ 204 از سرور backend

تشخیص

1. کد خطا و منبع خطا را برای خطای مشاهده شده با استفاده از API Monitoring، ابزار Trace یا گزارش‌های دسترسی NGINX، همانطور که در مراحل تشخیص مشترک توضیح داده شده است، تعیین کنید.
2. اگر کد خطا protocol.http.ResponseWithBody باشد و Fault Source مقدار target داشته باشد، این نشان می‌دهد که سرور backend با کد وضعیت 204 No Content یا 205 Reset Content به همراه بدنه پاسخ و/یا یکی از هدرهای ذکر شده در Possible causes پاسخ داده است.

3. برای تأیید اینکه آیا سرور backend واقعاً یک بدنه‌ی بار داده‌ی پاسخ و/یا یک یا چند مورد از هدرهای ذکر شده در علل احتمالی را ارسال کرده است، می‌توانید مراحل زیر را انجام دهید:

   1. اگر شما یک کاربر ابر عمومی هستید، و اگر می‌توانید درخواست API یکسانی را مستقیماً از هر یک از سیستم‌های خود به سرور backend ارسال کنید.

   2. اگر شما یک کاربر ابر خصوصی هستید، می‌توانید همان درخواست API را مستقیماً از یکی از پردازنده‌های پیام مرتبط با سازمان و محیطی خاص که در آن خرابی مشاهده شده است، به سرور backend ارسال کنید.

   3. پاسخ دریافتی از سرور backend را بررسی کنید و تأیید کنید که حاوی بدنه‌ی payload پاسخ و/یا یک یا چند مورد از هدرهای ذکر شده در بالا است. اگر بله، پس دلیل این خطا همین است.

      نمونه شماره ۱

      نمونه شماره ۱: پاسخ سرور Backend به شماره ۲۰۴ با هدر کدگذاری محتوا

      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
      

      در این نمونه، سرور backend با کد وضعیت 204 No Content و Content-Encoding: gzip پاسخ داد.

      نمونه شماره ۲

      نمونه شماره ۲: پاسخ سرور بک‌اند ۲۰۴ با هدر طول محتوا

      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
      

      در این نمونه، سرور backend با کد وضعیت 204 No Content و Content-Length: 48 پاسخ داد.

      نمونه شماره ۳

      نمونه شماره ۳: پاسخ سرور بک‌اند ۲۰۵ به همراه بدنه پاسخ

      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
      

      در این نمونه، سرور backend با کد وضعیت 205 Reset Content به همراه متن پاسخ پاسخ داد This is a sample Response.

   4. در تمام مثال‌های بالا، سرور backend کد وضعیت 204 No Content یا 205 Reset Content را به همراه متن پاسخ و/یا یکی از هدرهای ذکر شده در بخش «دلایل احتمالی» ارسال کرده است.
   5. بنابراین، Apigee Edge کد وضعیت 502 Bad Gateway را به همراه کد خطای protocol.http.ResponseWithBody ارسال کرد.

وضوح تصویر

اطمینان حاصل کنید که سرور backend هنگام ارسال پاسخ 204 No Content یا 205 Reset Content به Apigee Edge، همیشه به Specification RFC 7231، بخش 6.3.6: 205 Reset Content پایبند باشد. یعنی، سرور backend نباید موارد زیر را به عنوان بخشی از پاسخ 204 No Content یا 205 Reset Content ارسال کند:

1. بدنه بار پاسخ
2. و هر یک از سربرگ‌های زیر:
   1. Content-Length
   2. Content-Encoding
   3. Transfer-Encoding

مشخصات

اگر سرور backend پاسخ 204 No Content یا 205 Reset Content را ارسال کند، اما به مشخصات RFC زیر پایبند نباشد، Apigee Edge با کد وضعیت 502 Bad Gateway و کد خطای protocol.http.ResponseWithBody پاسخ می‌دهد:

نکات کلیدی قابل توجه

راه حل پیشنهادی این است که سرور backend را طوری تنظیم کنید که کد وضعیت 204 No Content و 205 Reset Content را بدون بدنه پاسخ و هیچ یک از هدرها - Content-Length ، Content-Encoding و Transfer-Encoding - ارسال کند و به مشخصات RFC 7231، بخش 6.3.5: 204 No Content و RFC 7231، بخش 6.3.6: 205 Reset Content پایبند باشد.

اگر هنوز به هرگونه کمکی از پشتیبانی Apigee نیاز دارید، به بخش «باید اطلاعات تشخیصی را جمع‌آوری کنید» بروید.

باید اطلاعات تشخیصی جمع‌آوری کند

اطلاعات تشخیصی زیر را جمع‌آوری کنید و سپس با پشتیبانی Apigee Edge تماس بگیرید:

اگر کاربر فضای ابری عمومی هستید، اطلاعات زیر را ارائه دهید:

• نام سازمان
• نام محیط
• نام پروکسی API
• دستور curl کامل که برای بازتولید خطای 502 استفاده می‌شود
• فایل ردیابی برای درخواست‌های API

اگر کاربر Private Cloud هستید، اطلاعات زیر را ارائه دهید:

• پیام خطای کامل مشاهده شده برای درخواست‌های ناموفق
• نام محیط
• بسته پروکسی API
• فایل ردیابی برای درخواست‌های API

• گزارش‌های دسترسی NGINX /opt/apigee/var/log/edge-router/nginx/ ORG ~ ENV . PORT# _access_log

  که در آن: ORG ، ENV و PORT# با مقادیر واقعی جایگزین شده‌اند.

• گزارش‌های سیستم پردازشگر پیام /opt/apigee/var/log/edge-message-processor/logs/system.log