502 بوابة غير صحيحة - ResponseWithBody

يتم الآن عرض مستندات Apigee Edge.
انتقِل إلى مستندات Apigee X. المعلومات

المشكلة

يحصل تطبيق العميل على رمز حالة HTTP 502 Bad Gateway مع رمز الخطأ protocol.http.ResponseWithBody كاستجابة لطلبات البيانات من واجهة برمجة التطبيقات.

رسالة الخطأ

يتلقى تطبيق العميل رمز الاستجابة التالي:

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، الفقرة 6.3.5: 204 بلا محتوى و RFC 7231، الفقرة 6.3.6: 205 إعادة ضبط المحتوى، يُتوقّع عدم إرسال أي محتوى إضافي كجزء من نص حمولة الاستجابة برمز الحالة 204 No Content أو 205 Reset Content من خلال خادم المصدر. وتشير عناوين الاستجابة، مثل Content-Length أو Content-Encoding أو Transfer-Encoding، إلى حجم حمولة الاستجابة أو نوعها أو تنسيقها.

نتيجةً لذلك، تعرض Apigee Edge رمز الحالة 502 Bad Gateway مع رمز الخطأ protocol.http.ResponseWithBody للعميل في الحالات التالية:

	رمز الحالة من خادم الخلفية
تحتوي الاستجابة الواردة من خادم الخلفية على	204 لا يوجد محتوى	205 إعادة ضبط المحتوى
نص الاستجابة	خطأ	خطأ
عنوان واحد (Content-Length) (تم الضبط على قيمة غير صفرية)	خطأ	خطأ
Content-Encoding (تم الضبط على ترميز متوافق في Apigee Edge)	خطأ	لا خطأ
Transfer-Encoding	خطأ	خطأ

في ما يلي الأسباب المحتملة لهذا الخطأ:

السبب	الوصف	تعليمات تحديد المشاكل وحلّها السارية على
نص الاستجابة أو العناوين التي تتضمّن استجابة 204 من خادم الخلفية	يرسل خادم الخلفية استجابة 204 No Content أو 205 Reset Content مع نص استجابة و/أو عنوان واحد أو أكثر من العناوين Content-Type أو Content-Encoding أو Transfer-Encoding.	مستخدمو Edge العام والخاص على السحابة الإلكترونية

خطوات التشخيص الشائعة

استخدِم إحدى الأدوات/الأساليب التالية لتشخيص هذا الخطأ:

السبب: نص الاستجابة أو العناوين ذات الاستجابة 204 من خادم الخلفية

التشخيص

1. حدِّد رمز الخطأ ومصدر الخطأ للخطأ الذي يتم رصده باستخدام مراقبة واجهة برمجة التطبيقات أو أداة التتبُّع أو سجلات الوصول إلى NGINX كما هو موضّح في خطوات التشخيص الشائعة.
2. إذا كان رمز الخطأ protocol.http.ResponseWithBody وكانت القيمة target لـ مصدر الخطأ، يشير ذلك إلى أنّ خادم الخلفية قد استجاب برمز حالة 204 No Content أو 205 Reset Content بنص الاستجابة و/أو أحد العناوين المذكورة في الأسباب المحتملة.

3. للتحقّق مما إذا كان الخادم الخلفي قد أرسل نصًا حمولة للاستجابة و/أو عنوانًا واحدًا أو أكثر من العناوين المذكورة في الأسباب المحتملة، يمكنك تنفيذ الخطوات التالية:

   1. إذا كنت من مستخدمي Public Cloud، وكان بإمكانك تقديم طلب البيانات نفسه من واجهة برمجة التطبيقات إلى الخادم الخلفي مباشرةً من أي من أنظمتك.

   2. إذا كنت مستخدمًا خاصًا في السحابة الإلكترونية، يمكنك إذن إرسال طلب البيانات نفسه من واجهة برمجة التطبيقات إلى الخادم الخلفي مباشرةً من أحد معالجي الرسائل المرتبطين بالمؤسسة والبيئة التي يتم فيها ملاحظة الخطأ.

   3. راجِع الاستجابة التي تم تلقّيها من الخادم الخلفي وتحقَّق من أنّها تحتوي على نص حمولة الاستجابة و/أو عنوان واحد أو أكثر من العناوين المذكورة أعلاه. إذا كانت الإجابة بنعم، إذًا هو سبب هذا الخطأ.

      النموذج الأول

      النموذج 1: استجابة خادم الخلفية 204 مع عنوان ترميز المحتوى

      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.

      النموذج الثاني

      النموذج الثاني: استجابة خادم الخلفية 204 مع عنوان طول المحتوى

      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.

      النموذج الثالث

      النموذج رقم 3: استجابة خادم الخلفية 205 مع نص الاستجابة

      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، الفقرة 6.3.6: 205 إعادة ضبط المحتوى، عند إرسال الاستجابة 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

المواصفات

يستجيب Apigee Edge برمز الحالة 502 Bad Gateway ورمز الخطأ protocol.http.ResponseWithBody إذا كان خادم الخلفية يرسل استجابة 204 No Content أو 205 Reset Content ولكنه لا يلتزم بمواصفات RFC التالية:

المواصفات
RFC 7231، القسم 6.3.5: 204 بلا محتوى
RFC 7231، الفقرة 6.3.6: 205 إعادة ضبط المحتوى

نقاط رئيسية يجب ملاحظتها

والحلّ المُقترَح هو إصلاح خادم الخلفية لإرسال رمز الحالة 204 No Content و205 Reset Content بدون نص الاستجابة وأيّ من العناوين - Content-Length وContent-Encoding وTransfer-Encoding والتقيّد بالمواصفات RFC 7231، القسم 6.3.5: 204 بلا محتوى و RFC 7231، القسم 6.3.6: 205 إعادة ضبط المحتوى.

إذا كنت لا تزال بحاجة إلى أي مساعدة من فريق دعم Apigee، يُرجى الانتقال إلى ضرورة جمع معلومات التشخيص.

ضرورة جمع معلومات التشخيص

اجمع معلومات التشخيص التالية، ثم تواصَل مع فريق دعم Apigee Edge:

إذا كنت من مستخدمي Cloud Cloud، يُرجى تقديم المعلومات التالية:

• اسم المؤسسة
• اسم البيئة
• اسم الخادم الوكيل لواجهة برمجة التطبيقات
• أكمِل أمر curl المستخدَم لإعادة إظهار الخطأ 502.
• ملف التتبُّع الخاص بطلبات واجهة برمجة التطبيقات

إذا كنت مستخدم Cloud خاصًا، يُرجى تقديم المعلومات التالية:

• رسالة الخطأ الكاملة التي تم رصدها للطلبات التي تعذّر تنفيذها
• اسم البيئة
• حزمة الخادم الوكيل لواجهة برمجة التطبيقات
• ملف التتبُّع الخاص بطلبات واجهة برمجة التطبيقات

• سجلات وصول 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