413 درخواست موجودیت خیلی بزرگ - TooBigBody

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

علامت

برنامه‌ی کلاینت، کد وضعیت HTTP 413 Request Entity Too Large به همراه کد خطای protocol.http.TooBigBody را به عنوان پاسخی برای فراخوانی‌های API دریافت می‌کند.

پیام خطا

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

HTTP/1.1 413 Request Entity Too Large

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

{
   "fault":{
      "faultstring":"Body buffer overflow",
      "detail":{
         "errorcode":"protocol.http.TooBigBody"
      }
   }
}

علل احتمالی

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

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

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

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

علت: حجم بار درخواستی بیشتر از حد مجاز است

تشخیص

1. کد خطا ، منبع خطا و اندازه بار درخواست را برای خطای مشاهده شده با استفاده از گزارش‌های دسترسی API Monitoring، Trace Tool یا NGINX همانطور که در مراحل تشخیص مشترک با سناریوی شماره ۱ (فشرده نشده) توضیح داده شده است، تعیین کنید.
2. اگر منبع خطا دارای policy یا proxy مقدار باشد، این نشان می‌دهد که اندازه بار درخواست ارسال شده توسط برنامه کلاینت به Apigee بیشتر از حد مجاز در Apigee Edge است.
3. اندازه بار درخواست را همانطور که از مرحله ۱ تعیین شده است، تأیید کنید.
   • اگر اندازه‌ی بار داده (payload size) بیش از ۱۰ مگابایت باشد، پس دلیل خطا همین است.
   • اگر اندازه‌ی بار داده کمتر از حد مجاز ۱۰ مگابایت باشد، ممکن است بار داده‌ی درخواست به صورت فشرده ارسال شده باشد. به علت بروید: اندازه‌ی بار داده‌ی درخواست پس از خارج کردن از حالت فشرده از حد مجاز فراتر رفته است.
4. همچنین می‌توانید با بررسی درخواست واقعی با استفاده از مراحل زیر، تأیید کنید که آیا اندازه بار درخواست واقعاً بالای 10 مگابایت است یا خیر:
   1. اگر به درخواست واقعی ارسال شده توسط برنامه کلاینت دسترسی ندارید، به Resolution بروید.
   2. اگر به درخواست واقعی ارسال شده توسط برنامه کلاینت دسترسی دارید، مراحل زیر را انجام دهید:
      1. اندازه‌ی payload ارسالی در درخواست را تأیید کنید.
      2. اگر متوجه شدید که اندازه‌ی payload بیشتر از حد مجاز در Apigee Edge است، پس مشکل از همین‌جا ناشی می‌شود.

      درخواست نمونه:

      curl http://<hostalias>/testtoobigbody -k -X POST -F file=@test15mbfile -v
      

      در مورد فوق، فایل test15mbfile حدود ۱۵ مگابایت است. اگر از کلاینت دیگری استفاده می‌کنید، لاگ‌های کلاینت را بررسی کنید تا اندازه‌ی payload ارسالی را متوجه شوید.

وضوح تصویر

به قسمت رزولوشن بروید.

علت: حجم بار درخواستی پس از رفع فشار از حد مجاز فراتر می‌رود.

اگر بار داده درخواست در قالب فشرده ارسال شود و هدر درخواست Content-Encoding روی gzip , Apigee بار داده درخواست را از حالت فشرده خارج می‌کند. در طول فرآیند خارج کردن از حالت فشرده، اگر Apigee متوجه شود که اندازه بار داده بیشتر از 10 مگابایت، یعنی حد مجاز ، است، خارج کردن بیشتر از حالت فشرده را متوقف می‌کند و بلافاصله با خطای 413 Request Entity Too Large with error code protocol.http.TooBigBody پاسخ می‌دهد.

تشخیص

1. کد خطا، منبع خطا ، را تعیین کنید و اندازه بار درخواستی برای خطای مشاهده شده با استفاده از گزارش‌های API Monitoring، Trace Tool یا NGINX Access همانطور که در مراحل تشخیص مشترک با سناریوی شماره ۲ (فشرده شده) توضیح داده شده است.
2. اگر منبع خطا دارای policy یا proxy مقدار باشد، این نشان می‌دهد که اندازه بار درخواست ارسال شده توسط برنامه کلاینت به Apigee بیشتر از حد مجاز در Apigee Edge است.
3. اندازه بار درخواست (Request Payload Size) را همانطور که در مرحله ۱ تعیین شده است، تأیید کنید.
   • اگر اندازه‌ی بار داده (payload size) بیش از ۱۰ مگابایت باشد، پس دلیل خطا همین است.
   • اگر اندازه‌ی بار داده کمتر از حد مجاز ۱۰ مگابایت باشد، ممکن است بار داده‌ی درخواست به صورت فشرده ارسال شده باشد. در این صورت، اندازه‌ی فشرده نشده‌ی بار داده‌ی درخواست فشرده را بررسی کنید.
4. شما می‌توانید با استفاده از یکی از روش‌های زیر، اعتبارسنجی کنید که آیا درخواست از طرف کلاینت در قالب فشرده ارسال شده است و اندازه فشرده نشده آن بزرگتر از حد مجاز است یا خیر:

   ردیابی

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

   1. اگر ردی از درخواست ناموفق گرفته‌اید، به مراحل تفصیلی در بخش ردگیری و
      1. مقدار متغیر client.received.content.length را تعیین کنید.
      2. بررسی کنید که آیا درخواست کلاینت حاوی هدر Content-Encoding: gzip بوده است یا خیر.
   2. اگر مقدار متغیر client.received.content.length بیشتر از 10 مگابایت، محدودیت مجاز و هدر درخواست Content-Encoding: gzip باشد، دلیل این خطا همین است.

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

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

   1. اگر به درخواست واقعی ارسال شده توسط برنامه کلاینت دسترسی ندارید، به Resolution بروید.
   2. اگر به درخواست واقعی ارسال شده توسط برنامه کلاینت دسترسی دارید، مراحل زیر را انجام دهید:
      1. اندازه‌ی payload ارسالی در درخواست را به همراه هدر Content-Encoding ارسالی در درخواست، تأیید کنید.

      2. بررسی کنید که آیا اندازه فشرده نشده payload بیشتر از حد مجاز در Apigee Edge است یا خیر.

         نمونه درخواست:

         curl https://<hostalias>/testtoobigbody -k -X POST -F file=@test15mbfile.gz -H "Content-Encoding: gzip" -v
         

         در مورد بالا، فایل test15mbfile.gz کمتر از محدودیت اندازه است؛ با این حال، اندازه فایل فشرده نشده test15mbfile حدود ۱۵ مگابایت است و هدر Content-Encoding آن gzip است.

         اگر از کلاینت دیگری استفاده می‌کنید، لاگ‌های کلاینت را بررسی کنید تا اندازه‌ی بار داده‌ی ارسالی و اینکه آیا هدر Content-Encoding روی gzip تنظیم شده است یا خیر را بیابید.

   گزارش‌های پردازنده پیام

   برای اعتبارسنجی با استفاده از گزارش‌های پردازشگر پیام:

   1. اگر شما یک کاربر ابر خصوصی هستید، می‌توانید از گزارش‌های پردازشگر پیام برای تعیین اطلاعات کلیدی در مورد خطاهای HTTP 413 استفاده کنید.

   2. لاگ‌های پردازشگر پیام را بررسی کنید:

      /opt/apigee/var/log/edge-message-processor/logs/system.log

   3. جستجو کنید تا ببینید آیا در یک بازه زمانی خاص خطای 413 وجود دارد یا خیر (اگر مشکل در گذشته رخ داده است) یا اینکه آیا درخواست‌هایی با 413 هنوز با شکست مواجه شده‌اند یا خیر.

      می‌توانید از رشته‌های جستجوی زیر استفاده کنید:

      grep -ri "chunkCount"
      

      grep -ri "RequestTooLarge"
      

   4. خطوطی مشابه زیر را در system.log خواهید یافت ( TotalRead و chunkCount ممکن است در مورد شما متفاوت باشند):

      2021-07-06 13:29:57,544  NIOThread@1 ERROR HTTP.SERVICE -
        TrackingInputChannel.checkMessageBodyTooLarge()
        : Message is too large.  TotalRead 10489856 chunkCount 2570
      
      2021-07-06 13:29:57,545  NIOThread@1 INFO  HTTP.SERVICE -
        ExceptionHandler.handleException()
        : Exception trace: com.apigee.errors.http.user.RequestTooLarge
        : Body buffer overflow

   5. در طول فرآیند رفع فشار، به محض اینکه پردازنده پیام تشخیص دهد که کل بایت‌های خوانده شده > 10 مگابایت است، متوقف شده و خط زیر را چاپ می‌کند:

      Message is too large.  TotalRead 10489856 chunkCount 2570

      این نشان می‌دهد که اندازه بار درخواست (Request Payload Size) بیش از ۱۰ مگابایت است و Apigee وقتی اندازه شروع به فراتر رفتن از حد مجاز ۱۰ مگابایت می‌کند، خطای RequestTooLarge را با کد خطا protocol.http.TooBigBody ارسال می‌کند.

وضوح تصویر

محدودیت‌ها

شرکت Apigee انتظار دارد که برنامه‌ی کلاینت و سرور backend، اندازه‌ی بار داده (payload) بزرگتر از حد مجاز، همانطور که برای Request/response size در Apigee Edge Limits مستند شده است، ارسال نکنند.

1. اگر شما یک کاربر ابر عمومی هستید، حداکثر محدودیت برای اندازه بار درخواست و پاسخ، همانطور که برای Request/response size در Apigee Edge Limits مستند شده است، می‌باشد.
2. اگر شما یک کاربر Private Cloud هستید، ممکن است محدودیت پیش‌فرض برای اندازه بار درخواست و پاسخ را تغییر داده باشید (هرچند که این یک روش توصیه شده نیست). می‌توانید حداکثر محدودیت اندازه بار درخواست را با دنبال کردن دستورالعمل‌های موجود در بخش «نحوه بررسی محدودیت فعلی» تعیین کنید.

چگونه حد فعلی را بررسی کنیم؟

این بخش توضیح می‌دهد که چگونه می‌توان تأیید کرد که ویژگی HTTPRequest.body.buffer.limit با مقدار جدیدی در پردازنده‌های پیام به‌روزرسانی شده است.

1. در دستگاه پردازشگر پیام، ویژگی HTTPRequest.body.buffer.limit را در دایرکتوری /opt/apigee/edge-message- processor/conf جستجو کنید و با استفاده از دستور زیر بررسی کنید که چه مقداری تنظیم شده است:

   grep -ri "HTTPRequest.body.buffer.limit" /opt/apigee/edge-message-processor/conf
   

2. نتیجه نمونه از دستور بالا به شرح زیر است:

   /opt/apigee/edge-message-processor/conf/http.properties:HTTPRequest.body.buffer.limit=10m

3. در خروجی مثال بالا، توجه کنید که ویژگی HTTPRequest.body.buffer.limit با مقدار 10m در http.properties تنظیم شده است.

   این نشان می‌دهد که محدودیت اندازه بار درخواست پیکربندی‌شده در Apigee برای Private Cloud، 10 مگابایت است.

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

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

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

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

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

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

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

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