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

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

المشكلة

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

رسالة الخطأ

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

HTTP/1.1 500 Internal Server Error

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

{
   "fault":{
      "faultstring":"Bad Form Data",
      "detail":{
         "errorcode":"protocol.http.BadFormData"
      }
   }
}

بيانات النموذج

قبل التطرق إلى تفاصيل تحديد هذه المشكلة وحلّها، لنتعرّف على ما هي بيانات النموذج.

بيانات النموذج هي المعلومات التي يقدّمها المستخدم عادةً من خلال نموذج HTML يتضمّن عناصر مثل مربّع إدخال نص أو زر أو مربّع اختيار. يتم إرسال بيانات النموذج بشكل عام على شكل سلسلة من أزواج المفتاح/القيمة كجزء من طلبات HTTP أو الاستجابات.

نقل بيانات النموذج

  1. Content-Type: application/x-www-form-urlcipher
    • إذا كان حجم بيانات النموذج صغيرًا، يتم إرسال البيانات كأزواج المفتاح/القيمة مع:

      نموذج طلب يتضمّن بيانات النموذج:

      curl https://HOSTALIAS/somepath -H "Content-Type: application/x-www-form-urlencoded" -d "username=abc@google.com&pasword=secret123"
      
    • أي أحرف ليست أبجدية رقمية في كلٍّ من المفتاح والقيم يتم ترميزها بالنسبة المئوية، أي يتم تمثيلها كحرف ثلاثي من حروف %HH، وتتكوّن من علامة نسبة مئوية متبوعة برقمين سداسيين عشريين يمثّلان رمز ASCII الخاص بالحرف المحدّد.
    • وبالتالي، مع أنّ علامة النسبة المئوية (%) مسموح بها في بيانات النموذج، يتم تفسيرها على أنّها بداية لتسلسل هروب خاص. وبالتالي، إذا كانت بيانات النموذج تتطلّب احتواء علامة النسبة المئوية (%) في المفتاح أو القيمة، يجب إرسالها على أنّها %25, التي تمثّل رمز ASCII لعلامة النسبة المئوية (%).
  2. نوع المحتوى: Multipart/form-data

    إذا أردت نقل كميات كبيرة من البيانات الثنائية أو النصوص التي تحتوي على أحرف غير ASCII، يمكنك إرسال البيانات باستخدام Content-Type: multipart/form-data كما هو موضّح في "نماذج Google"، القسم 17.13.4.2

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

لا يحدث هذا الخطأ إلا في حال استيفاء جميع الشروط التالية:

  1. يحتوي طلب HTTP الذي أرسله العميل إلى Apigee Edge على ما يلي:
    1. Content-Type: application/x-www-form-urlencoded، و
    2. بيانات النموذج التي تتضمّن علامة النسبة المئوية (%) أو علامة النسبة المئوية (%) متبوعة بأحرف سداسية عشرية غير صالحة غير مسموح بها وفقًا لـ "نماذج Google" - الفقرة 17.13.4.1.
  2. يقرأ الخادم الوكيل لواجهة برمجة التطبيقات في Apigee Edge معلَمات النموذج المحدّدة التي تحتوي على أي أحرف غير مسموح باستخدامها في مسار الطلب باستخدام سياسة استخراجVariables أو سياسة AssignMessage.

    على سبيل المثال، إذا كانت بيانات النموذج تحتوي على علامة النسبة المئوية (%) كما هي (بدون ترميز) أو علامة النسبة المئوية (%) متبوعة بأي أحرف سداسية عشرية غير صالحة في المفتاح و/أو القيمة، ستظهر عندئذٍ رسالة الخطأ هذه.

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

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

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

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

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

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

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

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

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

    (عرض صورة أكبر)

  7. يتم عرض المعلومات المتعلقة برمز الخطأ protocol.http.BadFormData كما هو موضّح أدناه:

    (عرض صورة أكبر)

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

  9. من نافذة السجلّات، دوِّن التفاصيل التالية:
    • رمز الحالة: 500
    • مصدر الخطأ: proxy
    • رمز الخطأ: protocol.http.BadFormData
    • سياسة الأخطاء: extractvariables/EV-ExtractFormParams
  10. إذا كان مصدر الخطأ هو proxy، يكون رمز الخطأ هو protocol.http.BadFormData، وقيمة سياسة الخطأ غير فارغة، في هذه الحالة، يشير ذلك إلى أنّ الخطأ حدث عندما كانت السياسة المحدّدة المُشار إليها في سياسة الأخطاء تقرأ أو تستخرج بيانات النموذج (معلَمات النموذج) التي تتضمّن أي أحرف لا يُسمح باستخدامها.
  11. في هذا المثال، تكون القيمة X-Apigee-fault-policy هي X-Apigee-fault-policy، ما يعني أنّ سياسة استخراجVariables المسماة X-Apigee-fault-policy لم تنجح أثناء قراءة معلَمات النموذج أو استخراجها.

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

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

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

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

    في نموذج تتبُّع النموذج أعلاه، تجدر الإشارة إلى حدوث خطأ في سياسة استخراج المتغيّرات المسماة EV-ExtractFormParams.

  6. انتقِل إلى العملية التي تحمل اسم خطأ بعد تعذُّر تنفيذ السياسة:

  7. لاحظ قيم ما يلي من التتبع:

    الخطأ: Bad Form Data

    الولاية: PROXY_REQ_FLOW

    error.class: com.apigee.rest.framework.BadRequestException

    • تشير قيمة الخطأ Bad Form Data إلى أنّ معلَمات النموذج تحتوي على بعض الأحرف غير المسموح باستخدامها.
    • تشير قيمة الحالة PROXY_REQ_FLOW, إلى حدوث الخطأ في تدفق الطلب للخادم الوكيل لواجهة برمجة التطبيقات.
  8. انتقِل إلى مرحلة AX (بيانات "إحصاءات Google" المسجّلة) في التتبُّع وانقر عليها.
  9. انتقِل للأسفل إلى قسم Stage Details (تفاصيل المرحلة) - Error Headers (عناوين الخطأ) وحدِّد قيم X-Apigee-error-code وX-Apigee-header-source وX-Apigee-Error-policy كما هو موضّح أدناه:

  10. يُرجى العلم أنّ قيمتَي X-Apigee-fault-code وX-Apigee-Error-source هما protocol.http.BadFormData وpolicy على التوالي، وأنّ قيمتَي X-Apigee-fault-code غير فارغة. ويشير هذا إلى أنّ الخطأ حدث عندما كانت السياسة المحدّدة المُشار إليها في X-Apigee-fault-policy تقرأ أو استخراج بيانات النموذج (معلَمات النموذج)، والتي تحتوي على أي أحرف X-Apigee-fault-policy باستخدامها.

    عناوين الاستجابة القيمة
    X-Apigee-fault-code protocol.http.BadFormData
    X-Apigee-fault-source policy
    X-Apigee-fault-policy extractvariables/EV-ExtractFormParams
  11. في هذا المثال، تكون قيمة X-Apigee-fault-policy هي extractvariables/EV- ExtractFormParams, ، ما يعني أنّ سياسة استخراجVariables المسماة EV-ExtractFormParams تعذّر إكمالها أثناء قراءة معلَمات النموذج أو استخراجها.

NGINX

لتشخيص الخطأ باستخدام سجلات الوصول إلى NGINX:

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

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

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

    نموذج الخطأ 500 من سجل وصول NGINX:

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

    العناوين القيمة
    X-Apigee-fault-code protocol.http.BadFormData
    X-Apigee-fault-source policy
    X-Apigee-fault-policy extractvariables/EV-ExtractFormParams
  5. يُرجى العلم أنّ قيَم X-Apigee-fault-code وX-Apigee-fault-code هي protocol.http.BadFormData، وpolicy على التوالي، وX-Apigee-fault-code غير فارغة. ويشير ذلك إلى أنّ الخطأ حدث أثناء استخدام السياسة المحدّدة المُشار إليها في X-Apigee-fault-policy,، أو استخراج بيانات النموذج (معلَمات النموذج)، والتي تحتوي على أي أحرف X-Apigee-fault-policy, باستخدامها.
  6. في هذا المثال، تكون قيمة X-Apigee-fault-policy هي extractvariables/EV- ExtractFormParams, ، ما يعني أنّ سياسة استخراجVariables المسماة EV-ExtractFormParams لم تنجح أثناء قراءة معلَمات النموذج.

السبب: تحتوي مَعلمات النموذج في الطلب على أحرف غير مسموح بها.

التشخيص

  1. حدِّد رمز الخطأ ومصدر الخطأ وسياسة الخطأ لدى 500 Internal Server Error باستخدام مراقبة واجهة برمجة التطبيقات أو أداة التتبُّع أو سجلات وصول NGINX كما هو موضّح في خطوات التشخيص الشائعة.
  2. إذا كان رمز الخطأ هو protocol.http.BadFormData، وقيمة مصدر الخطأ هي proxy، أو policy، وتكون سياسة الأخطاء فارغة، يشير ذلك إلى تعذّر إكمال السياسة المحدّدة في سياسة الأخطاء أثناء قراءة بيانات النموذج أو استخراجها (معلَمات النموذج).
  3. راجِع السياسة الموضّحة في سياسة الأخطاء وحدِّد المعلومات التالية:
    1. المصدر: حدد ما إذا كانت السياسة تقرأ البيانات أو تستخرجها من الطلب أو الاستجابة.
    2. معلَمات النماذج: يمكنك تحديد معلَمات النموذج التي تتم قراءتها في السياسة.

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

      النموذج الأول: استخراج مَعلمات نموذج استخراج سياسة استخراج المتغيّر:

            <ExtractVariables name="EV-ExtractFormParms">
               <DisplayName>EV-ExtractFormParams</DisplayName>
               <Source>request</Source>
               <FormParam name="username">
                  <Pattern ignoreCase="false">{username}</Pattern>
               </FormParam>
               <FormParam name="password">
                 <Pattern ignoreCase="false">{password}</Pattern>
               </FormParam>
               <VariablePrefix>forminfo</VariablePrefix>
             <IgnoreUnresolvedVariables>false</IgnoreUnresolvedVariables>
            </ExtractVariables>
            

      في سياسة "المتغيّرات" أعلاه:

      • المصدر: request

        ويُشار إلى ذلك من خلال العنصر <Source>.

      • معلمات النموذج: username وpassword

        ويُشار إلى ذلك من خلال عنصر <Pattern> داخل العنصر <FormParam>.

      يشير هذا إلى أنّ معلَمات النموذج username و/أو password التي تم تمريرها كجزء من طلب HTTP من العميل إلى Apigee Edge تحتوي على أحرف غير مسموح بها للاستخدام.

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

      النموذج 2: نسخ معلَمات نماذج سياسة AssignMessage:

            <AssignMessage continueOnError="false" enabled="true" name="AM-CopyFormParams">
              <Copy source="request">
                <FormParams>
                  <FormParam name="username"/>
                  <FormParam name="password"/>
                </FormParams>
              </Copy>
              <AssignTo createNew="true" transport="http" type="request"/>
            </AssignMessage>
            

      في سياسة "المتغيّرات" أعلاه:

      • المصدر: request

        ويُشار إلى ذلك من خلال السمة source في العنصر <Copy>.

      • معلمات النموذج: username وpassword

        ويُشار إلى ذلك من خلال السمة name في العنصر <FormParam>.

      يشير هذا إلى أنّ مَعلمتَي النموذج username أو password أو كلاهما اللذين تم ضبطهما كجزء من طلب HTTP من العميل إلى Apigee Edge تحتوي على أي أحرف غير مسموح بها للاستخدام.

  4. تحقَّق ممّا إذا كانت هناك أي أحرف غير مسموح بها باستخدام الأحرف في مَعلمات النموذج المحدّدة في الخطوة 3 باستخدام إحدى الطرق التالية:

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

    لإثبات الملكية باستخدام أداة التتبُّع:

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

        ( عرض صورة أكبر حجمًا)

      3. في المثال أعلاه، يُرجى العِلم أنّ معلَمة النموذج password تحتوي على علامة النسبة المئوية (%).
      4. بما أنّ علامة النسبة المئوية (%) تُستخدم أيضًا في ترميز النسبة المئوية للأحرف الخاصة، لا يمكن استخدامها كما هي في بيانات النموذج.
      5. لذلك، يستجيب Apigee Edge باستخدام 500 Internal Server Error مع رمز الخطأ protocol.http.BadFormData.

    الطلب الفعلي

    للتحقّق من استخدام الطلب الفعلي:

    1. إذا لم تتمكن من الوصول إلى الطلب الفعلي الذي تم إجراؤه على الخادم الهدف، فانتقل إلى الحل.
    2. إذا كان بإمكانك الوصول إلى الطلب الفعلي الذي تم إرساله إلى Apigee Edge، اتّبِع الخطوات التالية:
      1. يمكنك مراجعة محتوى بيانات النموذج ومعرفة ما إذا كان يحتوي على أي أحرف لا يُسمح باستخدامها، مثل علامة النسبة المئوية (%) أو علامة النسبة المئوية (%) متبوعة بأحرف سداسية عشرية غير صالحة.

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

        نموذج الطلب رقم 1: بيانات النموذج كجزء من الطلب

        curl -X GET "https://HOSTALIAS/myproxy -H "Content-Type: application/x-www-form-urlencoded" -d "client_id=123456abc123&client_secret=c23578%ZY"
        

        في هذا المثال، يُرجى العِلم أنّ العنصر client_secret يحتوي على علامة النسبة المئوية (%) متبوعة بأحرف سداسية عشرية غير صالحة ZY.

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

        نموذج الطلب رقم 2: بيانات النموذج التي يتم تمريرها في ملف:

        curl -X GET "https://HOSTALIAS/myproxy -H "Content-Type: application/x-www-form-urlencoded" -d @form_data.xml
        

        محتوى form_data.xml:

        xml=<user><username>abc1234@google.com</username><password>qwerty12345!@#$%</password></user>
        

        في هذا المثال، تجدر الإشارة إلى أنّ العنصر password يحتوي على علامة النسبة المئوية (%)، والتي يجب عدم تمريرها كما هي في بيانات النموذج.

    3. في المثالَين أعلاه، تحتوي بيانات النموذج المُرسَلة كجزء من طلب HTTP إلى Apigee Edge على أحرف غير مسموح باستخدامها.
    4. لذلك، يستجيب Apigee Edge باستخدام 500 Internal Server Error مع رمز الخطأ protocol.http.BadFormData.

درجة الدقّة

  1. تأكّد دائمًا من أنّ أي رموز خاصة في كل من المفاتيح والقيم الخاصة ببيانات النموذج أو المعلَمات التي تم إرسالها كجزء من طلب HTTP من قِبل العميل يتم ترميزها دائمًا على النحو الموضَّح في بيانات النموذج - application/x-www-form-urlcipher.
  2. بالنسبة إلى الأمثلة التي تمّت مناقشتها أعلاه، يمكنك حلّ المشاكل على النحو التالي:

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

    النموذج 1: بيانات النموذج التي تم تمريرها كجزء من الطلب:

    استخدِم أحرفًا سداسية عشرية صالحة تتطابق مع رمز ASCII لحرف محدّد. على سبيل المثال، إذا كنت تريد إرسال علامة الدولار ($)، استخدِم %24 كما هو موضّح أدناه:

    curl -X GET "https://HOSTALIAS/myproxy -H "Content-Type: application/x-www-form-urlencoded" -d "client_id=123456abc123&client_secret=c23578%24"
    

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

    نموذج الطلب رقم 2: بيانات النموذج التي يتم تمريرها في ملف:

    curl -X GET "https://HOSTALIAS/myproxy -H "Content-Type: application/x-www-form-urlencoded" -d @form_data.xml
    

    محتوى form_data.xml:

    استخدِم ترميز النسبة المئوية لعلامة النسبة المئوية (%)، التي تُعدِّل الملف ليصبح %25 كما هو موضّح أدناه:

    xml=<user><username>abc1234@google.com</username><password>qwerty12345!!@#$%25</password></user>
    

المواصفات

تتوقّع Apigee Edge أنّه يتم إرسال بيانات النموذج وفقًا للمواصفات التالية:

المواصفات
بيانات النموذج - application/x-www-form-urlcipher

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

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

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

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

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

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

المراجع