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

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

علامت

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

پیغام خطا

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

HTTP/1.1 500 Internal Server Error

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

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

داده های فرم

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

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

انتقال اطلاعات فرم

1. نوع محتوا: برنامه کاربردی/x-www-form-urlencoded
   • اگر اندازه داده های فرم کوچک باشد، داده ها به صورت جفت کلید-مقدار با:
     • نویسه‌های هر دو کلید طبق قوانین توضیح داده شده در فرم‌ها - بخش 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: multipart/form-data همانطور که در Forms - بخش 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 Public و Private Cloud

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

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

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

تشخیص

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

      نمونه شماره 1

      نمونه شماره 1: 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 ارسال می شود حاوی کاراکترهایی است که مجاز به استفاده نیستند .

      نمونه شماره 2

      نمونه شماره 2: تعیین پارامترهای فرم کپی کردن خط مشی Message:

            <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. بررسی کنید که آیا کاراکتری وجود دارد که مجاز به استفاده از کاراکترها در پارامترهای فرم مشخص شده در مرحله 3 با استفاده از یکی از روش های زیر نیست:

   ابزار ردیابی

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

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

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

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

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

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

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

   1. اگر به درخواست واقعی ارائه شده به سرور مورد نظر دسترسی ندارید، به Resolution بروید.
   2. اگر به درخواست واقعی ارسال شده به Apigee Edge دسترسی دارید، مراحل زیر را انجام دهید:
      1. محتویات داده‌های فرم را مرور کنید و ببینید آیا دارای نویسه‌هایی است که مجاز به استفاده نیستند مانند علامت درصد ( % ) یا علامت درصد ( % ) به دنبال آن نویسه های هگزادسیمال نامعتبر است.

         نمونه شماره 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

         نمونه درخواست شماره 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 کد خطا پاسخ می‌دهد.http.BadFormData.

قطعنامه

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

   نمونه شماره 1

   نمونه شماره 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

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

   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 نیاز دارید، به Must collect information diagnostic بروید.

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

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

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

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