500 خطأ في الخادم الداخلي - BadPath

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

المشكلة

يتلقّى تطبيق العميل رمز حالة HTTP بقيمة 500 Internal Server Error مع رمز الخطأ protocol.http.BadPath كاستجابة لطلبات البيانات من واجهة برمجة التطبيقات.

رسالة الخطأ

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

HTTP/1.1 500 Internal Server Error

بالإضافة إلى ذلك، قد تظهر لك رسالة الخطأ التالية:

{
   "fault":{
      "faultstring":"Invalid request path",
      "detail":{
         "errorcode":"protocol.http.BadPath"
      }
   }
}

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

يحدث هذا الخطأ إذا كان عنوان URL للطلب الخاص بخادم الخلفية، والذي يمثّله متغيّر التدفق target.url، يحتوي على path يبدأ بعلامة استفهام (?) بدلاً من شرطة مائلة للأمام (/)، وهو غير صالح.

وفقًا للمواصفات RFC 3986، القسم 3: عناصر البنية و RFC 3986، القسم 3.3: المسار:

  1. يتضمّن بناء جملة معرّف الموارد المنتظم (URI) المكوّنات التالية:

            foo://example.com:8042/over/there?name=ferret#nose
            \_/   \______________/\_________/ \_________/ \__/
             |            |            |            |       |
          scheme      authority       path        query   fragment
    
  2. عنصر path مطلوب ويجب أن يبدأ بـ شَرطة مائلة للأمام (/) دائمًا.

لذلك، إذا كان عنوان URL للطلب الخاص بخادم الخلفية يتضمّن مكوّن path يبدأ بعلامة استفهام (?) بدلاً من شرطة مائلة للأمام (/)، ستستجيب Apigee Edge بالرمز 500 Internal Server Error ورمز الخطأ protocol.http.BadPath.

على سبيل المثال: إذا كانت قيمة target.url هي https://www.mocktarget.apigee.net?json، سيحدث هذا الخطأ لأنّ path غير صالح، إذ يبدأ بعلامة استفهام (?) بدلاً من شرطة مائلة للأمام (/).

السبب الوصف تعليمات تحديد المشاكل وحلّها التي تنطبق على
يتضمّن عنوان URL لخادم الخلفية (target.url) مسارًا غير صالح يبدأ مكوّن المسار في عنوان URL لخادم الخلفية الذي تمثله متغيّرات التدفق target.url بعلامة استفهام (?) بدلاً من شرطة مائلة (/). مستخدمو Edge Public Cloud وEdge Private Cloud

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

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

API Monitoring

الإجراء 1: استخدام "مراقبة واجهة برمجة التطبيقات"

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

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

  3. انتقِل إلى صفحة تحليل > مراقبة واجهة برمجة التطبيقات > التحقيق.
  4. اختَر الفترة الزمنية المحدّدة التي لاحظت فيها الأخطاء.
  5. رسم بياني لرمز الخطأ مقابل الوقت

  6. اختَر الخلية التي تحتوي على رمز الخطأ protocol.http.BadPath كما هو موضح أدناه:

  7. يتم عرض معلومات حول رمز الخطأ protocol.http.BadPath كما هو موضح أدناه:

  8. انقر على عرض السجلات ووسِّع صف الطلب الذي تعذّر تنفيذه.

  9. من نافذة السجلّات، سجِّل التفاصيل التالية:
    • رمز الحالة: 500
    • مصدر الخطأ: target
    • رمز الخطأ: protocol.http.BadPath
  10. إذا كان مصدر الخطأ هو target وكان رمز الخطأ هو protocol.http.BadPath، يشير ذلك إلى أنّ عنوان URL الخاص بخادم الخلفية يتضمّن مسارًا غير صالح.

التتبّع

الإجراء رقم 2: استخدام أداة "التتبُّع"

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

  1. فعِّل جلسة التتبُّع، ثم اتّبِع إحدى الخطوتَين التاليتَين:
    • انتظِر إلى أن يظهر الخطأ 500 Internal Server Error، أو
    • إذا كان بإمكانك إعادة إظهار المشكلة، أرسِل طلب بيانات من واجهة برمجة التطبيقات لإعادة إظهارها 500 Internal Server Error
  2. تأكَّد من تفعيل خيار عرض جميع معلومات FlowInfo:

  3. اختَر أحد الطلبات التي تعذّر تنفيذها وافحص التتبُّع.
  4. تنقَّل بين مراحل التتبُّع المختلفة وحدِّد مكان حدوث الخطأ.
  5. سيظهر الخطأ عادةً في مسار بعد مرحلة بدء مسار الطلب المستهدَف كما هو موضّح أدناه:

  6. دوِّن قيمة الخطأ من التتبُّع:

    error: Invalid request path

    بما أنّ الخطأ يتم طرحه بواسطة Apigee Edge بعد مرحلة بدء مسار طلب الخادم الهدف، يشير ذلك إلى أنّ عنوان URL الخاص بخادم الخلفية يتضمّن مسارًا غير صالح. من المرجّح أن يحدث ذلك إذا تم تعديل متغيّر التدفق target.url (الذي يمثّل عنوان URL الخاص بخادم الخلفية) في Apigee Edge باستخدام مسار غير صالح من خلال إحدى السياسات في تدفق طلب الاستهداف.

  7. افحص القسم المتغيرات التي تم قراءتها وتعيينها في كل تدفق للخلف من تدفق الخطأ إلى مرحلة بدء تدفق الطلب المستهدف.
  8. حدِّد السياسة التي تم تعديل متغيّر التدفق target.url فيها:

    نموذج تتبُّع يعرض سياسة JavaScript التي عدّلت متغيّر التدفق target.url:

    في نموذج التتبُّع الموضّح أعلاه، لاحظ أنّه يتم تعديل قيمة متغيّر التدفق target.url في سياسة JavaScript باسم JS- SetTargetURL على النحو التالي: target.url : https://mocktarget.apigee.net?json

  9. يُرجى العِلم أنّ القيمة في target.url تتضمّن المكوّنات التالية:
    • النظام: https
    • authority: mocktarget.apigee.net
    • المسار: ?json
  10. بما أنّ مكوّن المسار يبدأ بعلامة استفهام (?) بدلاً من شرطة مائلة للأمام (/)، سيظهر لك الخطأ Invalid request path.
  11. انتقِل إلى مرحلة AX (تسجيل بيانات "إحصاءات Google") في التتبُّع وانقر عليها.
  12. انتقِل للأسفل إلى قسم تفاصيل المرحلة - عناوين الأخطاء وحدِّد قيمتَي X-Apigee-fault-code وX-Apigee-fault-source كما هو موضّح أدناه:

  13. ستظهر قيمتا X-Apigee-fault-code وX-Apigee-fault-source بالشكلين protocol.http.BadPath وtarget على التوالي، ما يشير إلى أنّ سبب هذا الخطأ هو أنّ عنوان URL لخادم الخلفية يتضمّن مسارًا غير صالح.

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

NGINX

الإجراء رقم 3: استخدام سجلّات الوصول إلى NGINX

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

  1. إذا كنت مستخدمًا في Private Cloud، يمكنك استخدام سجلات الوصول إلى NGINX لتحديد المعلومات الأساسية حول 500 Internal Server Error عبر HTTP.
  2. تحقَّق من سجلّات الوصول إلى NGINX:

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

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

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

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

    العناوين القيمة
    X-Apigee-fault-code protocol.http.BadPath
    X-Apigee-fault-source target

    لاحظ أنّ قيمتَي X-Apigee-fault-code وX-Apigee-fault-source هما protocol.http.BadPath وtarget على التوالي، ما يشير إلى أنّ هذا الخطأ ناتج عن أنّ عنوان URL لخادم الخلفية يتضمّن مسارًا غير صالح.

السبب: يحتوي عنوان URL لخادم الخلفية (target.url) على مسار غير صالح

التشخيص

  1. حدِّد رمز الخطأ ومصدر الخطأ لـ 500 Internal Server Error باستخدام "مراقبة واجهة برمجة التطبيقات" أو "أداة التتبُّع" أو سجلّات الوصول إلى NGINX كما هو موضّح في خطوات التشخيص الشائعة.
  2. إذا كان رمز الخطأ هو protocol.http.BadPath وكان مصدر الخطأ يتضمّن القيمة target، يشير ذلك إلى أنّ عنوان URL لخادم الخلفية يتضمّن مسارًا غير صالح.
  3. يتم تمثيل عنوان URL لخادم الخلفية بواسطة متغيّر التدفق target.url في Apigee Edge. يحدث هذا الخطأ عادةً إذا حاولت تعديل عنوان URL لخادم الخلفية (target.url) ديناميكيًا باستخدام أي من السياسات (ضمن الخادم الوكيل/التدفق المشترك) في تدفق طلبات الخادم المستهدف، بحيث يتضمّن مسارًا غير صالح.

  4. حدِّد ما إذا كان المتغيّر target.url يتضمّن مسارًا غير صالح ومصدر قيمته باستخدام إحدى الطريقتَين التاليتَين:

    التتبّع

    استخدام أداة "التتبُّع"

    إذا كنت قد سجّلت تتبُّعًا لهذا الخطأ، اتّبِع الخطوات الموضّحة في استخدام أداة "التتبُّع" و

    1. تحقَّق مما إذا كان target.url يتضمّن مسارًا غير صالح، أي إذا كان يبدأ بعلامة استفهام (?) بدلاً من شرطة مائلة للأمام (/).
    2. إذا كانت الإجابة بنعم، ابحث عن السياسة التي عدّلت قيمة target.url أو حدّثتها لتتضمّن مسارًا غير صالح.

      نموذج تتبُّع يعرض سياسة JavaScript التي عدّلت متغيّر التدفق target.url

    3. في نموذج التتبُّع أعلاه، لاحظ أنّ سياسة JavaScript قد عدّلت قيمة target.url أو غيّرتها لتتضمّن مسارًا غير صالح.
    4. يُرجى العِلم أنّ target.url يتضمّن المكوّنات التالية:
      • النظام: https
      • authority: mocktarget.apigee.net
      • المسار: ?json

      يبدأ المسار بعلامة استفهام (?) بدلاً من شرطة مائلة للأمام (/)، لذلك فهو غير صالح.

    السجلّات

    استخدام السجلّات في خادم السجلّات

    1. إذا لم يكن لديك تتبُّع لهذا الخطأ (مشكلة متقطّعة)، تحقَّق مما إذا كنت قد سجّلت المعلومات حول قيمة متغيّر التدفق target.url، باستخدام سياسات مثل MessageLogging أو ServiceCallout إلى خادم السجلّ.
    2. إذا كانت لديك السجلات، راجِعها واتّبِع الخطوات التالية:
      1. تأكَّد مما إذا كان target.url يتضمّن مسارًا غير صالح، و
      2. معرفة ما إذا كان بإمكانك تحديد المعلومات المتعلقة بالسياسة التي تم تعديلها target.url لتتضمّن مسارًا غير صالح

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

    مراجعة خادم وكيل واجهة برمجة التطبيقات الذي يتعذّر تنفيذه

    إذا لم يكن لديك تتبُّع أو سجلّات لهذا الخطأ، راجِع خادم وكيل واجهة برمجة التطبيقات الذي تعذّر تنفيذه لتحديد ما تم تعديله أو تحديثه في متغيّر التدفق target.url ليحتوي على مسار غير صالح. تحقق مما يلي:

    • السياسة داخل خادم وكيل لواجهة برمجة التطبيقات
    • أي مسارات مشترَكة يتم استدعاؤها من الخادم الوكيل
  5. افحص السياسة المحدّدة بعناية (على سبيل المثال: AssignMessage أو JavaScript) التي تعدّل أو تحدّث متغيّر التدفق target.url، وحدِّد سبب تعديل target.url ليكون له مسار غير صالح.

    في ما يلي بعض الأمثلة على السياسات التي تعدّل متغيّر التدفق target.url بشكل غير صحيح ليحتوي على مسار غير صالح يؤدي إلى حدوث هذا الخطأ.

    العيّنة رقم 1

    المثال 1: متغيّر target.url لتعديل سياسة JavaScript

    var url = "https://mocktarget.apigee.net?json"
    context.setVariable("target.url", url);

    في المثال أعلاه، لاحظ أنّه يتم تعديل متغيّر التدفق target.url بالقيمة https://mocktarget.apigee.net?json الواردة في متغيّر آخر url..

    يُرجى العِلم أنّ قيمة url تتضمّن المكوّنات التالية:

    • النظام: https
    • authority: mocktarget.apigee.net
    • المسار: ?json

    يبدأ المسار بعلامة استفهام (?) بدلاً من شرطة مائلة للأمام (/)، وهو غير صالح. لذلك، تعرض Apigee Edge 500 Internal Server Error مع رمز الخطأ protocol.http.BadPath.

    النموذج رقم 2

    المثال 2: تعديل متغيّر target.url في سياسة JavaScript استنادًا إلى القيمة في عنوان الطلب

    var path = context.getVariable("request.header.Path");
    var url = "https://mocktarget.apigee.net" + path
    context.setVariable("target.url", url);

    في المثال أعلاه، لاحظ أنّه يتم تعديل متغيّر التدفق target.url من خلال ربط القيمة https://mocktarget.apigee.net الواردة في المتغيّر url بالقيمة الواردة في المتغيّر path، والتي يتم استرداد قيمتها من request.header.Path..

    إذا كان بإمكانك الوصول إلى الطلب أو التتبُّع الفعلي، يمكنك التحقّق من القيمة الفعلية التي تم تمريرها إلى request.header.Path.

    طلب عيّنة من المستخدم

    curl -v https://HOST_ALIAS/v1/myproxy -H "Authorization: Bearer <token> -H "Path: ?user"
    

    في هذا المثال، لا يتم إرسال مسار العنوان كجزء من الطلب. وبالتالي، تكون قيمة المتغيّر path في سياسة JavaScript هي null.

    وبالتالي:

    • url = https://mocktarget.apigee.net + path
    • url = https://mocktarget.apigee.net + "?user"
    • target.url = https://mocktarget.apigee.net?user

    يُرجى العِلم أنّ قيمة target.url تتضمّن المكوّنات التالية:

    • النظام: https
    • authority: mocktarget.apigee.net
    • المسار: ?user

    يبدأ المسار بعلامة استفهام (?) بدلاً من شرطة مائلة للأمام (/)، وهو غير صالح. وبالتالي، تعرض Apigee Edge القيمة 500 Internal Server Error مع رمز الخطأ protocol.http.BadPath.

    المثال 3

    المثال 3: سياسة AssignMessage التي تعدّل المتغيّر target.url

    <AssignMessage async="false" continueOnError="false" enabled="true" name="AM-SetTargetURL">
        <DisplayName>AM-SetTargetURL</DisplayName>
        <AssignVariable>
             <Name>target.url</Name>
             <Value>https://mocktarget.apigee.net?echo</Value>
        </AssignVariable>
        <IgnoreUnresolvedVariables>true</IgnoreUnresolvedVariables>
        <AssignTo createNew="false" transport="http" type="request"/>
    </AssignMessage>

    يُرجى العِلم أنّ قيمة url تتضمّن المكوّنات التالية:

    • النظام: https
    • authority: mocktarget.apigee.net
    • المسار: ?echo

    في هذا المثال أيضًا، يبدأ المسار بعلامة استفهام (?) بدلاً من شرطة مائلة للأمام (/)، وهو غير صالح. لذلك، تعرض Apigee Edge الرمز 500 Internal Server Error مع رمز الخطأ protocol.http.BadPath.

الدقة

وفقًا لمواصفات عنوان URL RFC 3986، الفقرة 3: عناصر البنية، فإنّ المكوِّن path إلزامي ويجب أن يبدأ دائمًا بالعلامة "/". لذا، اتّبِع الخطوات التالية لحلّ هذه المشكلة:

  1. تأكَّد من أنّ عنوان URL لخادم الخلفية، الممثّل بمتغيّر التدفق target.url، يتضمّن دائمًا مسارًا صالحًا وأنّه يبدأ دائمًا بشرطة مائلة للأمام (/).
    1. في بعض الحالات، قد لا يتضمّن المسار اسم مورد، لذا تأكَّد من أنّ المسار يتضمّن على الأقل شرطة مائلة للأمام (/).
    2. إذا كنت تستخدم أي متغيّرات أخرى لتحديد قيمة متغيّر المسار target.url، فتأكَّد من أنّ المتغيّرات الأخرى لا تتضمّن مسارًا غير صالح.
    3. إذا أجريت أي عمليات على السلاسل لتحديد قيمة متغيّر التدفق target.url، فتأكَّد من أنّ نتيجة عمليات السلاسل أو نتيجتها لا تتضمّن مسارًا غير صالح.
  2. في الأمثلة الموضّحة أعلاه، يمكنك حلّ هذه المشكلة كما هو موضّح أدناه:

    العيّنة رقم 1

    المثال 1: متغيّر target.url لتعديل سياسة JavaScript

    استخدِم شرطة مائلة (/) بدلاً من علامة استفهام (?) في المتغيّر url لحلّ هذه المشكلة كما هو موضّح أدناه:

    var url = "https://mocktarget.apigee.net/json"
    context.setVariable("target.url", url);

    النموذج رقم 2

    المثال 2: تعديل متغيّر target.url في سياسة JavaScript استنادًا إلى القيمة في عنوان الطلب

    var path = context.getVariable("request.header.Path");
    var url = "https://mocktarget.apigee.net" + path
    context.setVariable("target.url", url);

    تأكَّد من إدخال مسار صالح، مثل /user، كجزء من عنوان الطلب Path لحلّ هذه المشكلة كما هو موضّح أدناه:

    نموذج طلب:

    curl -v https://HOST_ALIAS/v1/myproxy -H "Authorization: Bearer <token> -H "Path: /user"
    

    المثال 3

    المثال 3: تعديل متغير target.url في سياسة AssignMessage

    أضِف مسارًا صالحًا في العنصر <Value> لسياسة AssignMessage. أي استبدِل علامة الاستفهام (?) بـ شرطة مائلة للأمام (/) في العنصر <Value> واضبطها على https://mocktarget.apigee.net/echo لحلّ هذه المشكلة كما هو موضّح أدناه:

    <AssignMessage async="false" continueOnError="false" enabled="true" name="AM-SetTargetURL">
        <DisplayName>AM-SetTargetURL</DisplayName>
        <AssignVariable>
             <Name>target.url</Name>
             <Value>https://mocktarget.apigee.net/echo</Value>
        </AssignVariable>
        <IgnoreUnresolvedVariables>true</IgnoreUnresolvedVariables>
        <AssignTo createNew="false" transport="http" type="request"/>
    </AssignMessage>

    المواصفات

    تتوقع Apigee Edge أن يبدأ path المكوّن في عنوان URL لخادم الخلفية دائمًا بشرطة مائلة للأمام (/) وفقًا للمواصفات التالية:

    المواصفات
    RFC 3986، الفقرة 3: مكوّنات البنية
    RFC 3986، الفقرة 3.3: المسار

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

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

    إذا استمرت المشكلة حتى بعد اتّباع التعليمات أعلاه، اجمع معلومات التشخيص التالية، ثم تواصَل مع فريق الدعم في Apigee Edge:

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

    • اسم المؤسسة
    • اسم البيئة
    • اسم خادم وكيل لواجهة برمجة التطبيقات
    • أكمِل الأمر curl المستخدَم لإعادة إنتاج 500 Internal Server Error مع رمز الخطأ protocol.http.BadPath
    • ملف التتبُّع لطلبات البيانات من واجهة برمجة التطبيقات

    إذا كنت مستخدمًا في Private 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

    المراجع

    متغيّرات التدفق - الهدف