400 طلب غير صالح - رأس الصفحة

أنت الآن بصدد الاطّلاع على مستندات Apigee Edge.
انتقِل إلى مستندات Apigee X.
info

المشكلة

يتلقّى تطبيق العميل رمز حالة HTTP 400 Bad Request مع رمز الخطأ protocol.http.DuplicateHeader كردّ على طلبات البيانات من واجهة برمجة التطبيقات.

رسالة الخطأ

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

HTTP/1.1 400 Bad Request

بالإضافة إلى ذلك، قد تظهر لك رسالة خطأ مشابهة للرسالة الموضّحة أدناه:

{
   "fault":{
      "faultstring":"Duplicate Header \"Expires\"",
      "detail":{
         "errorcode":"protocol.http.DuplicateHeader"
      }
   }
}

الأسباب المحتملة

يحدث هذا الخطأ إذا ظهر عنوان HTTP معيّن غير مسموح بتكراره في Apigee Edge أكثر من مرة بقيم متطابقة أو مختلفة كجزء من طلب HTTP أرسله العميل إلى Apigee Edge.

وفقًا للمعيار RFC 7230، القسم 3.2.2: ترتيب الحقول، يجب ألا ينشئ المرسل حقول عناوين متعددة بالاسم نفسه في الرسالة ما لم يتم تعريف قيمة الحقل بأكملها لذلك حقل العنوان كقائمة قيم مفصولة بفاصلة، [أي #(values)] أو أنّ حقل العنوان هو استثناء معروف. إذا عثرت Apigee Edge على عنوان معيّن لا يُسمح بتكراره أكثر من مرة في طلب HTTP المرسَل من العميل، ستستجيب برمز الحالة 400 Bad Request ورمز الخطأ protocol.http.DuplicateHeader.

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

السبب الوصف تعليمات تحديد المشاكل وحلّها التي تنطبق على
عنوان مكرّر في الطلب يحتوي طلب HTTP من تطبيق العميل إلى Apigee على عناوين مكرّرة. مستخدمو Edge Public Cloud وEdge Private Cloud

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

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

API Monitoring

لتشخيص الخطأ باستخدام "مراقبة واجهة برمجة التطبيقات"، اتّبِع الخطوات التالية:

  1. سجِّل الدخول إلى واجهة مستخدم Apigee Edge بصفتك مستخدمًا لديه دور مناسب.
  2. انتقِل إلى المؤسسة التي تريد التحقيق في المشكلة فيها.

  3. انتقِل إلى صفحة تحليل > مراقبة واجهة برمجة التطبيقات > التحقيق.
  4. اختَر الفترة الزمنية المحدّدة التي لاحظت فيها الأخطاء.
  5. تأكَّد من ضبط فلتر "الخادم الوكيل" على الكل.
  6. رسم بياني لرمز الخطأ مقابل الوقت
  7. اختَر خلية تحتوي على رمز الخطأ protocol.http.DuplicateHeader كما هو موضّح أدناه:

  8. تظهر المعلومات حول رمز الخطأ protocol.http.DuplicateHeader كما هو موضّح أدناه:

  9. انقر على عرض السجلات ووسِّع صف الطلب الذي تعذّر تنفيذه.
  10. من نافذة السجلّات، سجِّل التفاصيل التالية:
    1. رمز الحالة: 400
    2. مصدر الخطأ: apigee
    3. رمز الخطأ: protocol.http.DuplicateHeader
  11. إذا كان مصدر الخطأ يتضمّن القيمة apigee أو MP وكان رمز الخطأ يتضمّن القيمة protocol.http.DuplicateHeader، يشير ذلك إلى أنّ طلب HTTP من العميل كان يتضمّن عناوين مكرّرة.

أداة التتبُّع

NGINX

لتشخيص الخطأ باستخدام سجلّات الوصول إلى NGINX، اتّبِع الخطوات التالية:

  1. إذا كنت مستخدمًا في Private Cloud، يمكنك استخدام سجلّات الوصول إلى NGINX لتحديد المعلومات الأساسية حول أخطاء HTTP 400.
  2. تحقَّق من سجلّات الوصول إلى NGINX:

    /opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log

    حيث: يتم استبدال ORG وENV وPORT# بالقيم الفعلية.

  3. ابحث لمعرفة ما إذا كانت هناك أي أخطاء 400 خلال مدة زمنية معيّنة (إذا حدثت المشكلة في الماضي) أو إذا كانت هناك أي طلبات لا تزال غير ناجحة مع ظهور 400.
  4. إذا عثرت على أي أخطاء 400 مع X-Apigee-fault-code مطابقة لقيمة protocol.http.DuplicateHeader، حدِّد قيمة X-Apigee-fault-source.

    مثال على الخطأ 400 من سجلّ الوصول إلى NGINX:

    يحتوي نموذج الإدخال أعلاه من سجلّ الوصول إلى NGINX على القيم التالية لـ X-Apigee- fault-code وX-Apigee-fault-source:

    عناوين الاستجابة القيمة
    X-Apigee-fault-code protocol.http.DuplicateHeader
    X-Apigee-fault-source MP

السبب: عنوان مكرّر في الطلب

التشخيص

  1. حدِّد رمز الخطأ ومصدر الخطأ للخطأ الذي تم رصده باستخدام ميزة "مراقبة واجهة برمجة التطبيقات" أو سجلات الوصول إلى NGINX كما هو موضّح في خطوات التشخيص الشائعة.
  2. إذا كان مصدر الخطأ يتضمّن القيمة apigee أو MP، يشير ذلك إلى أنّ الطلب الذي أرسله تطبيق العميل إلى Apigee يحتوي على عناوين مكرّرة.
  3. يمكنك تحديد العنوان الفعلي الذي يتم إرساله أكثر من مرة كجزء من الطلب باستخدام إحدى الطرق التالية:

    رسالة الخطأ

    استخدام رسالة الخطأ

    1. إذا كان بإمكانك الوصول إلى رسالة الخطأ الكاملة التي تلقّيتها من Apigee Edge، يُرجى الرجوع إلى faultstring. يحتوي الرمز faultstring على اسم الرأس الذي تم إرساله أكثر من مرة.

      نموذج رسالة الخطأ:

      "faultstring":"Duplicate Header \"Expires\""
    2. في رسالة الخطأ أعلاه، يمكنك ملاحظة أنّه تم إرسال العنوان Expires أكثر من مرة، كما هو موضّح في faultstring.

    الطلب الفعلي

    استخدام الطلب الفعلي

    1. إذا كان بإمكانك الوصول إلى الطلب الفعلي الذي أرسله تطبيق العميل، اتّبِع الخطوات التالية:

      1. تحقَّق من قائمة العناوين التي تم تمريرها في الطلب.
      2. إذا تبيّن لك أنّ عنوانًا معيّنًا يظهر أكثر من مرّة في الطلب مع القيمة نفسها أو قيم مختلفة، سيكون ذلك هو سبب هذا الخطأ.

      نموذج طلب:

      curl https://HOST_ALIAS/duplicateheadertest -v -H "Expires: Mon, 21 June 2021 07:28:00 GMT" -H "Expires: Mon, 21 June 2021 07:28:00 GMT"
      

      في مثال الطلب أعلاه، يتم إرسال العنوان Expires أكثر من مرة. لذلك، يتعذّر تنفيذ هذا الطلب ويظهر الخطأ 400 Bad Request ورمز الخطأ: protocol.http.DuplicateHeader.

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

الدقة

حلّ مشكلة التكرار

الخيار 1 [الخيار المُقترَح]: إصلاح تطبيق العميل لعدم تضمين رؤوس مكرّرة

  1. تحليل سبب إرسال العميل المحدّد لعنوان مكرّر على سبيل المثال، Expires في الحالة أعلاه. تأكَّد من أنّه لا بأس في أن تقبل خوادم وكيل واجهة برمجة التطبيقات العنوان المكرّر. وعادةً، لا يُنصح بذلك وفقًا لمواصفات HTTP RFC7230.
  2. إذا لم يكن ذلك مرغوبًا فيه، عدِّل تطبيق العميل لكي لا يرسل عناوين مكرّرة.

    في المثال المذكور أعلاه، نلاحظ أنّه يتم إرسال العنوان Expires مرتين بالقيمة نفسها، وهو أمر غير مرغوب فيه. يمكنك حلّ المشكلة من خلال تمرير عنوان Expires مرة واحدة فقط كما هو موضّح أدناه:

    curl https://HOST_ALIAS/duplicateheadertest -v -H "Expires: Mon, 21 June 2021 07:28:00 GMT"
    
  3. إذا كان ذلك مرغوبًا فيه وكنت تريد السماح بالعناوين المكرّرة، انتقِل إلى الخيار 2: استخدام الموقع CwC.

CwC

الخيار 2: استخدام موقع "الربط والمشاركة"

توفّر Apigee السمة CwC HTTPHeader.<HeaderName> التي تتيح لتطبيقات العميل وخوادم الاستهداف إرسال عناوين مكرّرة إلى خوادم وكيلة لواجهة برمجة التطبيقات في Apigee Edge.

موقع إلكتروني أو تطبيق CwC القيم
HTTPHeader.<HeaderName> allowDuplicates,multivalued

على سبيل المثال، يمكن ضبط السمة التالية على &quot;معالجات الرسائل&quot; للسماح بالتكرارات والقيم المتعددة للعنوان Expires.

HTTPHeader.Expires=allowDuplicates, multiValued
  1. إذا كنت مستخدمًا للسحابة الإلكترونية الخاصة، يمكنك ضبط الموقع لمنع Apigee Edge من عرض الخطأ 400 Bad Request، حتى إذا كان الطلب يتضمّن عناوين مكرّرة، وذلك باستخدام دليل الإرشادات ضبط معالِجات الرسائل لاستخدام العناوين المكرّرة.
  2. إذا كنت من مستخدمي السحابة الإلكترونية العامة، يُرجى التواصل مع فريق دعم Apigee Edge لإعداد هذه السمة لمؤسستك.

المواصفات

تتوقّع Apigee ألا يرسل تطبيق العميل عناوين مكرّرة كجزء من الطلب وفقًا لمواصفات RFC التالية:

المواصفات
RFC 7230، القسم 3.2.2: ترتيب الحقول
RFC 7230، الفقرة 3.2 حقول العناوين

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

يجب جمع معلومات التشخيص

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

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

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

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

  • رسالة الخطأ الكاملة التي تم رصدها للطلبات التي تعذّر تنفيذها
  • اسم البيئة
  • حِزمة خادم وكيل لواجهة برمجة التطبيقات
  • أكمِل الأمر curl الذي استخدمته لإعادة إظهار الخطأ 400
  • ملف التتبُّع لطلبات البيانات من واجهة برمجة التطبيقات
  • سجلّات الوصول إلى 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