‫۵۰۲ دروازه نادرست - 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 از سرور پشتیبان به Apigee Edge یا 204 No Content یا 205 Reset Content باشد اما حاوی بدنه پاسخ و/یا یک یا چند مورد از سرایندهای زیر باشد:

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

طبق مشخصات RFC 7231، بخش ۶.۳.۵: 204 No Content (محتوایی وجود ندارد) و RFC 7231، بخش ۶.۳.۶: 205 Reset Content (بازنشانی محتوا)، انتظار می‌رود که هیچ محتوای اضافه‌ای به‌عنوان بخشی از بدنه بار پاسخ با کد وضعیت 204 No Content یا 205 Reset Content توسط سرور مبدأ ارسال نشود. سرایندهای پاسخ مثل Content-Length، Content-Encoding، یا Transfer-Encoding اندازه، نوع، یا قالب بار پاسخ را نشان می‌دهند.

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

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

مراحل متداول تشخیص خرابی

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

علت: بدنه پاسخ یا سرایندها با پاسخ ۲۰۴ از سرور زیرینه

تشخیص

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

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

   1. اگر کاربر «ابر عمومی» هستید و اگر می‌توانید همان درخواست میانای برنامه‌سازی کاربردی را مستقیماً از هریک از سیستم‌هایتان به سرور پشتیبان ارسال کنید.

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

   3. پاسخ دریافتی از سرور پشتیبان را بررسی کنید و مطمئن شوید که حاوی بدنه بار پاسخ و/یا یک یا چند سرصفحه ذکرشده در بالا است. اگر پاسخ مثبت است، این دلیل این خطا است.

      نمونه شماره ۱

      نمونه شماره ۱: پاسخ سرور زیرینه ۲۰۴ با سرایند «کدبندی محتوا»

      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
      

      در این نمونه، سرور زیرینه با کد وضعیت 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
      

      در این نمونه، سرور زیرینه با کد وضعیت 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
      

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

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

وضوح

مطمئن شوید که سرور پشتیبان همیشه از «مشخصات» RFC 7231، بخش ۶.۳.۶: 205 Reset Content، هنگام ارسال پاسخ 204 No Content یا 205 Reset Content به Apigee Edge پیروی می‌کند. یعنی سرور زیرینه نباید موارد زیر را به‌عنوان بخشی از 204 No Content یا پاسخ 205 Reset Content ارسال کند:

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

مشخصات

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

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

راه‌حل پیشنهادی این است که سرور پشتیبان را اصلاح کنید تا کد وضعیت 204 No Content و 205 Reset Content را بدون بدنه پاسخ و هریک از سرایندهای Content-Length، Content-Encoding، و Transfer-Encoding ارسال کند و از مشخصات RFC 7231، بخش ۶.۳.۵: ۲۰۴ بدون محتوا و RFC 7231، بخش ۶.۳.۶: ۲۰۵ بازنشانی محتوا پیروی کند.

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

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

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

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

• نام سازمان
• نام محیط
• نام پراکسی میانای برنامه‌سازی کاربردی
• فرمان کامل curl برای بازتولید خطای 502 استفاده شد
• فایل ردیابی برای درخواست‌های 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