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

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

علامت

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

پیغام خطا

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

HTTP/1.1 413 Request Entity Too Large

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

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

علل احتمالی

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

در اینجا دلایل احتمالی این خطا وجود دارد:

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

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

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

تشخیص

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

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

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

      در مورد بالا، فایل test15mbfile فایل ~15 مگابایت است. اگر از مشتری دیگری استفاده می کنید، گزارش های مشتری را دریافت کنید تا اندازه بار ارسال شده را بدانید.

قطعنامه

به Resolution بروید.

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

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

تشخیص

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

   ردیابی

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

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

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

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

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

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

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

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

         در مورد بالا، فایل test15mbfile.gz کمتر از حد مجاز است. با این حال، اندازه فایل فشرده نشده test15mbfile فایل ~15 مگابایت است و هدر Content-Encoding gzip است.

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

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

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

   1. اگر کاربر Private Cloud هستید، می‌توانید از گزارش‌های پردازشگر پیام برای تعیین اطلاعات کلیدی درباره خطاهای 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 بیش از 10 مگابایت است و Apigee خطای RequestTooLarge زمانی که اندازه شروع به تجاوز از حد مجاز 10 مگابایت با کد خطا به عنوان protocol.http.TooBigBody می کند، پرتاب می کند.http.TooBigBody

قطعنامه

محدودیت ها

Apigee انتظار دارد که برنامه کلاینت و سرور پشتیبان اندازه های باری بیشتر از حد مجاز را که برای Request/response size در Apigee Edge Limits مستند شده است ارسال نکند.

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

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

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

1. در دستگاه Message Processor، ویژگی 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 نیاز دارید، به Must collect information diagnostic بروید.

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

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

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

• نام سازمان
• نام محیط زیست
• نام پروکسی 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