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

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

المشكلة

يحصل تطبيق العميل على رمز حالة 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 و Private Cloud

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

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

مراقبة واجهة برمجة التطبيقات

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

  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. إذا كنت مستخدمًا للسحابة الإلكترونية الخاص، يمكنك استخدام سجلات وصول 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 Access على القيم التالية لـ X-Apigee- رمز الخطأ وX-Apigee-error-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 استخدام سمة CwC

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

سمة CwC القيم
HTTPHeader.<HeaderName> allowDuplicates,multivalued

فعلى سبيل المثال، يمكن تعيين الخاصية التالية على معالِجات معالجة الرسائل للسماح بالتكرارات قيم متعددة للعنوان Expires. 

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

المواصفات

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

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

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

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

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

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

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

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

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