500 خطای سرور داخلی - BadFormData

شما در حال مشاهده مستندات Apigee Edge هستید.
به مستندات Apigee X مراجعه کنید . اطلاعات

علامت

برنامه‌ی کلاینت، کد وضعیت HTTP با 500 Internal Server Error را به همراه کد خطای protocol.http.BadFormData به عنوان پاسخی برای فراخوانی‌های API دریافت می‌کند.

پیام خطا

برنامه‌ی کلاینت کد پاسخ زیر را دریافت می‌کند:

HTTP/1.1 500 Internal Server Error

علاوه بر این، ممکن است پیام خطای زیر را مشاهده کنید:

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

داده‌های فرم

قبل از اینکه به جزئیات عیب‌یابی این مشکل بپردازیم، بیایید بفهمیم که داده‌های فرم چیستند.

داده‌های فرم، اطلاعاتی هستند که توسط کاربر معمولاً از طریق یک فرم HTML که دارای عناصری مانند کادر ورودی متن، دکمه یا کادر انتخاب است، ارائه می‌شوند. داده‌های فرم معمولاً به صورت مجموعه‌ای از جفت‌های کلید-مقدار به عنوان بخشی از درخواست‌ها یا پاسخ‌های HTTP ارسال می‌شوند.

انتقال داده از طریق فرم

1. نوع محتوا: application/x-www-form-urlencoded
   • اگر اندازه داده‌های فرم کوچک باشد، داده‌ها به صورت جفت‌های کلید-مقدار با موارد زیر ارسال می‌شوند:
     • کاراکترهای هر دو کلید طبق قوانین توضیح داده شده در Forms - بخش 17.13.4.1 کدگذاری شده‌اند.
     • Content-Type: application/x-www-form-urlencoded

     نمونه درخواست با داده‌های فرم:

     curl https://HOSTALIAS/somepath -H "Content-Type: application/x-www-form-urlencoded" -d "username=abc@google.com&pasword=secret123"
     

   • هر کاراکتر غیرحرفی-عددی در هر دو کلید و مقدار، به صورت درصد کدگذاری می‌شود، یعنی به صورت یک سه‌تایی کاراکتری %HH نمایش داده می‌شوند که شامل یک علامت درصد و به دنبال آن دو رقم هگزادسیمال است که نشان دهنده کد ASCII آن کاراکتر خاص است.
   • بنابراین، اگرچه علامت درصد ( % ) در داده‌های فرم مجاز است، اما به عنوان شروع یک توالی فرار ویژه تفسیر می‌شود. بنابراین، اگر داده‌های فرم نیاز به داشتن علامت درصد ( % ) در کلید یا مقدار داشته باشند، باید به صورت %25, ارسال شوند که نشان دهنده کد ASCII برای کاراکتر علامت درصد ( % ) است.
2. نوع محتوا: چندبخشی/فرم-داده

   اگر می‌خواهید حجم زیادی از داده‌های دودویی یا متن حاوی کاراکترهای غیر ASCII را ارسال کنید، می‌توانید داده‌ها را با Content-Type: چندبخشی/فرم-داده، همانطور که در فرم‌ها - بخش 17.13.4.2 توضیح داده شده است، ارسال کنید.

علل احتمالی

این خطا فقط و فقط در صورتی رخ می‌دهد که تمام شرایط زیر برقرار باشد:

1. درخواست HTTP ارسال شده توسط کلاینت به Apigee Edge شامل موارد زیر است:
   1. Content-Type: application/x-www-form-urlencoded و
   2. داده‌های فرم با علامت درصد ( % ) یا علامت درصد ( % ) و به دنبال آن کاراکترهای هگزادسیمال نامعتبر که طبق فرم‌ها مجاز نیستند - بخش 17.13.4.1 .

2. پروکسی API در Apigee Edge پارامترهای فرم خاص حاوی هر کاراکتری را که استفاده از آن در جریان درخواست با استفاده از ExtractVariables یا سیاست AssignMessage مجاز نیست، می‌خواند.

   برای مثال، اگر داده‌های فرم حاوی علامت درصد ( % ) به همان صورت (بدون کدگذاری) یا علامت درصد ( % ) باشند، اگر به دنبال آن کاراکترهای هگزادسیمال نامعتبر در کلید و/یا مقدار وجود داشته باشد، این خطا را دریافت خواهید کرد.

   در اینجا علل احتمالی این خطا آورده شده است:

   علت	توضیحات	دستورالعمل‌های عیب‌یابی قابل اجرا برای
   پارامترهای فرم در درخواست دارای کاراکترهای غیرمجاز هستند	پارامترهای فرم که به عنوان بخشی از درخواست HTTP توسط کلاینت ارسال می‌شوند، شامل هر کاراکتری هستند که مجاز به استفاده از آنها نیستیم .	کاربران فضای ابری عمومی و خصوصی Edge

مراحل تشخیص مشترک

برای تشخیص این خطا از یکی از ابزارها/تکنیک‌های زیر استفاده کنید:

علت: پارامترهای فرم در درخواست دارای کاراکترهای غیرمجاز هستند

تشخیص

1. کد خطا ، منبع خطا و سیاست خطا را برای 500 Internal Server Error با استفاده از مانیتورینگ API، ابزار Trace یا گزارش‌های دسترسی NGINX، همانطور که در مراحل تشخیص مشترک توضیح داده شده است، تعیین کنید.
2. اگر کد خطا protocol.http.BadFormData باشد، منبع خطا مقدار proxy یا policy داشته باشد و Fault Policy خالی نباشد ، این نشان می‌دهد که سیاست مشخص شده در Fault Policy هنگام خواندن یا استخراج داده‌های فرم (پارامترهای فرم) با شکست مواجه شده است.
3. سیاست ذکر شده در سیاست خطا را بررسی کنید و اطلاعات زیر را تعیین کنید:
   1. منبع: تعیین می‌کند که آیا سیاست، داده‌ها را از درخواست یا پاسخ می‌خواند یا استخراج می‌کند.
   2. پارامترهای فرم: پارامترهای فرم خاصی را که در خط‌مشی خوانده می‌شوند، تعیین کنید.

      نمونه شماره ۱

      نمونه شماره ۱: سیاست ExtractVariables برای استخراج پارامترهای فرم:

            <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>
            

      در سیاست ExtractVariables فوق:

      • منبع: request

        این توسط عنصر <Source> نشان داده می‌شود.

      • پارامترهای فرم: username و password

        این توسط عنصر <Pattern> درون عنصر <FormParam> نشان داده می‌شود.

      این نشان می‌دهد که پارامترهای فرم username و/یا password که به عنوان بخشی از درخواست HTTP توسط کلاینت به Apigee Edge ارسال شده‌اند، حاوی کاراکترهایی هستند که مجاز به استفاده از آنها نیستیم .

      نمونه شماره ۲

      نمونه شماره ۲: سیاست 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>
            

      در سیاست ExtractVariables فوق:

      • منبع: request

        این توسط ویژگی source در عنصر <Copy> نشان داده شده است.

      • پارامترهای فرم: username و password

        این توسط ویژگی name در عنصر <FormParam> نشان داده شده است.

      این نشان می‌دهد که پارامترهای فرم username یا password یا هر دو، که به عنوان بخشی از درخواست HTTP توسط کلاینت به Apigee Edge ارسال می‌شوند، حاوی کاراکترهایی هستند که مجاز به استفاده از آنها نیستیم .

4. با استفاده از یکی از روش‌های زیر، بررسی کنید که آیا کاراکترهایی وجود دارند که استفاده از آنها در پارامترهای فرم مشخص شده در مرحله ۳ مجاز نباشد :

   ابزار ردیابی

   برای اعتبارسنجی با استفاده از ابزار Trace:

   1. اگر همانطور که در مراحل تشخیص مشترک توضیح داده شد، ردپای درخواست ناموفق را ثبت کرده‌اید، یکی از درخواست‌های ناموفق را انتخاب کنید.
   2. اگر تشخیص داده‌اید که پارامترهای فرم حاوی کاراکترهایی هستند که مجاز به استفاده نیستند ، بخشی از درخواست HTTP در مرحله 3 بالا هستند، پس
      1. به مرحله‌ی «درخواست دریافتی از کلاینت» بروید.

      2. به بخش جزئیات فاز (Phase Details) بروید و محتوای درخواست (Request Content) را بررسی کنید.

         ( تصویر را بزرگتر ببینید )

         
      3. در مثال بالا، توجه داشته باشید که پارامتر فرم password شامل علامت درصد ( % ) است.
      4. از آنجایی که علامت درصد ( % ) برای کدگذاری درصد کاراکترهای ویژه نیز استفاده می‌شود، نمی‌توان آن را به همین صورت در داده‌های فرم استفاده کرد.
      5. بنابراین، Apigee Edge با 500 Internal Server Error و کد خطای protocol.http.BadFormData پاسخ می‌دهد.

   درخواست واقعی

   برای اعتبارسنجی با استفاده از درخواست واقعی:

   1. اگر به درخواست واقعی ارسال شده به سرور هدف دسترسی ندارید، به Resolution بروید.
   2. اگر به درخواست واقعی ارسال شده به Apigee Edge دسترسی دارید، مراحل زیر را انجام دهید:
      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 .

         نمونه شماره ۲

         نمونه درخواست شماره ۲: داده‌های فرم در یک فایل ارسال می‌شوند:

         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 عنصر password شامل علامت درصد ( % ) است که نباید به همین صورت در داده‌های فرم ارسال شود.

   3. در دو مثال بالا، داده‌های فرم ارسال شده به عنوان بخشی از درخواست HTTP به Apigee Edge حاوی کاراکترهایی هستند که استفاده از آنها مجاز نیست .
   4. بنابراین، Apigee Edge با 500 Internal Server Error و کد خطای protocol.http.BadFormData پاسخ می‌دهد.

وضوح تصویر

1. اطمینان حاصل کنید که هرگونه کاراکتر خاص در کلیدها و مقادیر داده‌های فرم یا پارامترهای ارسالی به عنوان بخشی از درخواست HTTP توسط کلاینت، همیشه مطابق آنچه در Form Data - application/x-www-form-urlencoded توضیح داده شده است، کدگذاری می‌شوند.
2. برای مثال‌های مورد بحث در بالا، می‌توانید مشکلات را به صورت زیر برطرف کنید:

   نمونه شماره ۱

   نمونه شماره ۱: داده‌های فرم به عنوان بخشی از درخواست ارسال می‌شوند:

   از کاراکترهای هگزادسیمال معتبری استفاده کنید که با کد ASCII برای یک کاراکتر خاص مطابقت داشته باشند. برای مثال، اگر می‌خواهید علامت دلار ( $ ) را ارسال کنید، %24 مانند تصویر زیر استفاده کنید:

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

   نمونه شماره ۲

   نمونه درخواست شماره ۲: داده‌های فرم در یک فایل ارسال می‌شوند:

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

   محتویات form_data.xml:

   از کدگذاری درصد برای علامت درصد ( % ) استفاده کنید، یعنی فایل را طوری تغییر دهید که %25 داشته باشد. %25 همانطور که در زیر نشان داده شده است:

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

مشخصات

Apigee Edge انتظار دارد که داده‌های فرم طبق مشخصات زیر ارسال شوند:

اگر هنوز به هرگونه کمکی از پشتیبانی Apigee نیاز دارید، به بخش «باید اطلاعات تشخیصی را جمع‌آوری کنید» بروید.

باید اطلاعات تشخیصی جمع‌آوری کند

اگر مشکل حتی پس از دنبال کردن دستورالعمل‌های بالا ادامه داشت، اطلاعات تشخیصی زیر را جمع‌آوری کنید و سپس با پشتیبانی Apigee Edge تماس بگیرید:

اگر کاربر فضای ابری عمومی هستید، اطلاعات زیر را ارائه دهید:

• نام سازمان
• نام محیط
• نام پروکسی API
• دستور curl کامل که برای تولید مجدد 500 Internal Server Error با کد خطا protocol.http.BadFormData استفاده می‌شود.
• فایل ردیابی برای درخواست‌های API

اگر کاربر Private Cloud هستید، اطلاعات زیر را ارائه دهید:

• پیام خطای کامل مشاهده شده برای درخواست‌های ناموفق
• نام محیط
• بسته پروکسی API
• فایل ردیابی برای درخواست‌های API

• گزارش‌های دسترسی 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

منابع

• انواع محتوای فرم
• RFC3986، بخش ۲.۱: کدگذاری درصد
• کدگذاری درصد
• کاراکترهای هگزادسیمال