‫۵۰۰ خطای سرور داخلی - 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. Content-Type: application/x-www-form-urlencoded
   • اگر اندازه داده‌های فرم کوچک باشد، داده‌ها به‌صورت جفت‌های کلید-مقدار با موارد زیر ارسال می‌شود:
     • نویسه‌های هر دو کلید طبق قوانین توضیح‌داده‌شده در «فرم‌ها» - بخش ۱۷.۱۳.۴.۱ کدبندی می‌شوند.
     • سرایند 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. Content-Type: multipart/form-data

   اگر می‌خواهید مقادیر زیادی داده باینری یا نوشتاری حاوی نویسه‌های غیرASCII انتقال دهید، می‌توانید داده‌ها را با Content-Type: multipart/form-data ارسال کنید، همان‌طور که در «فرم‌ها - بخش ۱۷.۱۳.۴.۲» توضیح داده شده است

علل احتمالی

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

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

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

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

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

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

مراحل متداول تشخیص خرابی

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

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

تشخیص

1. بااستفاده از «پایش میانای برنامه‌سازی کاربردی»، ابزار «ردیابی»، یا گزارش‌های دسترسی NGINX، همان‌طور که در مراحل تشخیص خرابی متداول توضیح داده شده است، کد خطا، منبع خطا، و خط‌مشی خطا را برای 500 Internal Server Error تعیین کنید.
2. اگر کد خطا برابر با protocol.http.BadFormData باشد، منبع خطا مقدار proxy یا 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. بررسی کنید که آیا نویسه‌هایی وجود دارد که مجاز نیستند به‌عنوان نویسه‌های استفاده‌شده در پارامترهای فرم که در مرحله ۳ شناسایی شده‌اند استفاده شوند یا نه، بااستفاده از یکی از روش‌های زیر:

   ابزار ردیابی

   برای راستی‌آزمایی بااستفاده از ابزار «ردیابی»:

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

      2. به بخش جزئیات فاز پیمایش کنید و محتوای درخواست را بررسی کنید.

         ( مشاهده تصویر بزرگ‌تر)

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

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

وضوح

1. مطمئن شوید که همه نویسه‌های ویژه در کلیدها و مقادیر داده‌های فرم یا پارامترهایی که به‌عنوان بخشی از درخواست HTTP توسط مشتری ارسال می‌شوند، همیشه طبق آنچه در داده‌های فرم - 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 را داشته باشد، همان‌طور که در زیر نشان داده شده است:

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

مشخصات

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

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

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

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

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

• نام سازمان
• نام محیط
• نام پراکسی میانای برنامه‌سازی کاربردی
• فرمان کامل curl برای بازتولید 500 Internal Server Error با کد خطای protocol.http.BadFormData استفاده شد
• فایل ردیابی برای درخواست‌های 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، بخش ۲.۱: کدبندی درصدی
• کدبندی درصدی
• نویسه‌های دستگاه شانزده‌شانزدهی