413 كيان الطلب كبير جدًا - OverBigBody

أنت تعرض مستندات Apigee Edge.
انتقل إلى مستندات Apigee X. معلومات

المشكلة

يحصل تطبيق العميل على رمز حالة HTTP 413 Request Entity Too Large. برمز الخطأ protocol.http.TooBigBody كاستجابة لطلبات البيانات من واجهة برمجة التطبيقات.

رسالة الخطأ

يحصل تطبيق العميل على رمز الاستجابة التالي: 

HTTP/1.1 413 Request Entity Too Large

بالإضافة إلى ذلك، قد تلاحظ رسالة الخطأ التالية: 

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

الأسباب المحتملة

يحدث هذا الخطأ في حال إرسال حجم الحمولة من تطبيق العميل إلى Apigee Edge كجزء من طلب HTTP أكبر من الحد المسموح به في Apigee Edge .

في ما يلي الأسباب المحتملة لهذا الخطأ :

السبب الوصف إرشادات استكشاف الأخطاء وإصلاحها التي تنطبق على
حجم حمولة الطلب أكبر من الحد المسموح به حجم حمولة البيانات الذي يرسله تطبيق العميل كجزء من طلب HTTP إلى Apigee Edge هو تجاوز الحد المسموح به في Apigee Edge. مستخدمو Edge Public و Private Cloud
يتجاوز حجم حمولة الطلب الحد المسموح به بعد فك الضغط حجم حمولة البيانات الذي يتم إرساله بتنسيق مضغوط بواسطة تطبيق العميل كجزء من HTTP إرسال طلب إلى Apigee Edge يتجاوز الحد المسموح به عند فك ضغطه باستخدام Apigee Edge. مستخدمو Edge Public و Private Cloud

خطوات التشخيص الشائعة

استخدِم إحدى الأدوات/الأساليب التالية لتشخيص هذا الخطأ:

مراقبة واجهة برمجة التطبيقات

لتشخيص الخطأ باستخدام مراقبة واجهة برمجة التطبيقات:

  1. سجِّل الدخول إلى واجهة مستخدم Apigee Edge كمستخدم باستخدام الدور المناسب.

  2. انتقِل إلى المؤسسة التي تريد التحقيق في المشكلة فيها.

  3. انتقل إلى تحليل > مراقبة واجهة برمجة التطبيقات > التحقيق في الصفحة.
  4. اختَر الفترة الزمنية المحدّدة التي لاحظت فيها الأخطاء.
  5. يمكنك اختيار فلتر الخادم الوكيل لتضييق نطاق رمز الخطأ.
  6. ارسم رمز الخطأ مقابل الوقت.

  7. اختَر خلية تحتوي على رمز الخطأ protocol.http.TooBigBody وكذلك رمز الحالة 413كما هو موضّح أدناه:

  8. يتم عرض معلومات عن رمز الخطأ protocol.http.TooBigBody على النحو التالي: كما هو موضح أدناه:

  9. انقر على عرض السجلات ووسِّع صف الطلب الذي تعذّر تنفيذه. ثم من السجلات، لاحظ التفاصيل كما هو موضح أدناه :

    غير مضغوط

    السيناريو 1: إرسال الحمولة في نموذج غير مضغوط

    من نافذة السجلّات، دوِّن التفاصيل التالية:

    • رمز الحالة: 413
    • مصدر الخطأ: proxy
    • رمز الخطأ: protocol.http.TooBigBody.
    • طول الطلب(بالبايت): 15360440 (حوالي 15 ميغابايت)

    إذا كانت قيمة المصدر الخطأ هي proxy، يصبح رمز الخطأ على القيمة protocol.http.TooBigBody وطول الطلب أكبر من 10 ميغابايت، فإنها تشير إلى أن طلب HTTP من العميل يحتوي على طلب حجم أكبر من الحد المسموح به في Apigee.

    مضغوط

    السيناريو 2: إرسال الحمولة في شكل مضغوط

    من نافذة السجلات، يُرجى ملاحظة التفاصيل التالية:

    • رمز الحالة: 413
    • مصدر الخطأ: proxy
    • رمز الخطأ: protocol.http.TooBigBody.
    • طول الطلب(بايت): 15264 (حوالي 15 كيلوبايت)

    إذا كانت قيمة المصدر الخطأ هي proxy، يصبح رمز الخطأ على القيمة protocol.http.TooBigBody وطول الطلب هو أقل من 10 ميغابايت، فإنها تشير إلى أن طلب HTTP من العميل يحتوي على أن تطلب حجم حمولة أقل من الحد المسموح به في التنسيق المضغوط، ولكن حجم الحمولة أكبر من الحد المسموح به عند فك ضغطه باستخدام Apigee.

التتبّع

لتشخيص الخطأ باستخدام أداة التتبُّع:

  1. فعِّل جلسة التتبع وإمّا
    • انتظِر إلى أن يحدث الخطأ 413 Request Entity Too Large أو
    • إذا كان بإمكانك إعادة إنتاج المشكلة، عليك طلب بيانات من واجهة برمجة التطبيقات وإعادة إنتاجها. خطأ واحد (413 Request Entity Too Large)

  2. تأكَّد من تفعيل عرض كل معلومات التدفق.

  3. اختَر أحد الطلبات التي تعذّر تنفيذها وافحص عملية التتبُّع.
  4. انتقِل إلى المرحلة تم استلام الطلب من العميل.

    غير مضغوط

    السيناريو 1: إرسال الحمولة في نموذج غير مضغوط

    يُرجى مراعاة المعلومات التالية:

    • ترميز المحتوى: غير متوفّر
    • طول المحتوى: 15360204

    مضغوط

    السيناريو 2: إرسال الحمولة في شكل مضغوط

    يُرجى مراعاة المعلومات التالية:

    • ترميز المحتوى: gzip
    • طول المحتوى: 14969
    • نوع المحتوى: application/x-gzip
  5. يمكنك التنقّل خلال مراحل عملية التتبُّع المختلفة وتحديد مكان حدوث الفشل.

  6. ستجد الخطأ عادةً في مسار بعد عرض الطلب المستلَم من العميل كما هو موضّح أدناه:

  7. سجِّل قيمة الخطأ من عملية التتبُّع. يوضّح نموذج التتبّع أعلاه ما يلي:
    • الخطأ: Body buffer overflow
    • error.class: com.apigee.errors.http.user.RequestTooLarge

  8. انتقِل إلى Response Sent to Client (تم إرسال الردّ إلى العميل) وراجِع قيم الخطأ من يُظهر نموذج التتبّع أدناه ما يلي:

    • الخطأ: 413 Request Entity Too Large
    • محتوى الخطأ: {"fault":{"faultstring":"Body buffer overflow","detail":{"errorcode":"protocol.http.TooBigBody"}}}
  9. انتقِل إلى مرحلة AX (البيانات المسجَّلة في "إحصاءات Google") في عملية التتبُّع وانقر عليها.

  10. في قسم تفاصيل المرحلة، انتقِل للأسفل حتى تصل إلى قراءة المتغيّرات.

  11. حدِّد قيمة المتغير client.payd.content.length ، ما يشير إلى ما يلي:
    • الحجم الفعلي لحمولة الطلب عند إرسالها بتنسيق غير مضغوط
    • حجم حمولة الطلب عند فك الضغط بواسطة Apigee، عندما تكون الحمولة يتم إرسالها بتنسيق مضغوط. وستظل دائمًا كما هي مع قيمة الحد الأقصى المسموح به (10 ميغابايت) في هذا السيناريو.

    غير مضغوط

    السيناريو 1: الحمولة لطلب في نموذج غير مضغوط

    متغيّر client.payd.content.length: 15360204

    مضغوط

    السيناريو 2: طلب الحمولة بتنسيق مضغوط

    متغيّر client.payd.content.length: 10489856

  12. يوضّح الجدول التالي سبب عرض الخطأ 413 بواسطة Apigee ضمن السيناريوهين استنادًا إلى قيمة المتغير client.payd.content.length:
    السيناريو قيمة client.payd.content.length سبب التعذُّر
    طلب الحمولة بتنسيق غير مضغوط 15 ميغابايت تقريبًا الحجم > يبلغ الحد الأقصى المسموح به 10 ميغابايت.
    طلب الحمولة بتنسيق مضغوط 10 ميغابايت تقريبًا

    تم تجاوز الحد الأقصى للحجم عند فك الضغط

NGINX

لتشخيص الخطأ باستخدام سجلات وصول NGINX:

  1. إذا كنت مستخدمًا للسحابة الإلكترونية الخاص، يمكنك استخدام سجلات وصول NGINX لتحديد المعلومات الأساسية حول أخطاء HTTP 413.

  2. تحقق من سجلات وصول NGINX:

    /opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log

  3. ابحث لمعرفة ما إذا كانت هناك أي أخطاء 413 خلال مدة محدّدة (إذا حدثت مشكلة في الماضي) أو إذا كانت هناك أي طلبات لا تزال تخفق مع 413
  4. إذا ظهرت أي أخطاء 413 في رمز الخطأ X-Apigee-fault-code قيمة protocol.http.TooBigBody، ثم حدِّد قيمة X-Apigee-fault-source.

    غير مضغوط

    السيناريو 1 : طلب حجم حمولة البيانات بتنسيق غير مضغوط

    يحتوي إدخال النموذج أعلاه من سجلّ وصول NGINX على القيم التالية لكلّ من X-Apigee-fault-code وX-Apigee-fault-code

    عناوين الردود القيمة
    X-Apigee-fault-code protocol.http.TooBigBody
    X-Apigee-fault-sourc policy

    يُرجى ملاحظة أنّ طول الطلب: 15360440 (14.6 ميغابايت > الحدّ المسموح به).

    مضغوط

    السيناريو 2 : طلب حجم حمولة البيانات بتنسيق مضغوط

    يتضمن إدخال النموذج أعلاه من سجل وصول NGINX القيم التالية X-Apigee-fault-code وX-Apigee-fault-code

    عناوين الردود القيمة
    X-Apigee-fault-code protocol.http.TooBigBody
    X-Apigee-fault-source policy

    يُرجى الاطّلاع على مدة الطلب: 15264 (الحد الأقصى المسموح به هو 14.9 ألف شخص).

    في هذا السيناريو، تعرض Apigee Edge 413 على الرغم من مدة الطلب أقل من الحد المسموح به نظرًا لأن الطلب قد تم إرسالها بتنسيق مضغوط ويتجاوز حجم الحمولة الحد عند فك الضغط بواسطة Apigee Edge.

السبب: حجم حمولة الطلب أكبر من الحد المسموح به

التشخيص

  1. حدِّد رمز الخطأ ومصدر الخطأ وحجم حمولة الطلب تم رصد خطأ باستخدام سجلات وصول "مراقبة واجهة برمجة التطبيقات" أو أداة التتبع أو NGINX كما هو موضح في خطوات التشخيص الشائعة مع السيناريو 1 (غير مضغوط).
  2. إذا كانت قيمة المصدر الخطأ policy أو proxy، فعندئذ سيتم يشير إلى أنّ حجم حمولة الطلب الذي يرسله تطبيق العميل إلى Apigee أكبر من الحد المسموح به في Apigee Edge.
  3. تحقَّق من حجم حمولة الطلب كما هو محدّد في الخطوة 1.
  4. يمكنك أيضًا التحقّق مما إذا كان حجم حمولة الطلب > يُسمح بـ 10 ميغابايت كحد أقصى بحلول للتحقّق من الطلب الفعلي باتّباع الخطوات التالية:
    1. إذا لم يكن لديك إذن الوصول إلى الطلب الفعلي المقدَّم من تطبيق العميل، انتقِل إلى الحلّ:
    2. إذا كان لديك إذن بالوصول إلى الطلب الفعلي الذي أرسله تطبيق العميل، فنفِّذ الخطوات التالية:
      1. تحقَّق من حجم الحمولة التي تم تمريرها في الطلب.
      2. إذا وجدت أن حجم الحمولة أكبر من الحد المسموح به في Apigee Edge، فيكون هذا هو سبب المشكلة.

        3. نموذج طلب:

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

        في الحالة المذكورة أعلاه، يبلغ حجم الملف test15mbfile حوالي 15 ميغابايت. إذا كنت تستخدم برنامجًا آخر، احصل على سجلات العميل لمعرفة حجم الحمولة الذي يتم إرساله.

الدقة

انتقِل إلى درجة الدقة.

السبب: تجاوز حجم حمولة الطلب الحد المسموح به بعد فك الضغط

في حال إرسال حمولة الطلب بتنسيق مضغوط وعنوان الطلب تم ضبط Content-Encoding على gzip, تفكك Apigee ضغط الطلب. حمولة البيانات. أثناء عملية فك الضغط، إذا وجد Apigee أن حجم الحمولة أكبر أقل من 10 ميغابايت، الحد المسموح به، ثم يوقف عملية فك الضغط الإضافية ويستجيب مباشرةً مع 413 Request Entity Too Large مع رمز الخطأ protocol.http.TooBigBody

التشخيص

  1. حدِّد رمز الخطأ ومصدر الخطأ وحجم حمولة الطلب. للخطأ الذي تمت ملاحظته باستخدام سجلات API Monitoring أو Trace Tool أو NGINX Access كما هو موضح في خطوات التشخيص الشائعة مع السيناريو 2 (مضغوط).
  2. إذا كانت قيمة المصدر الخطأ policy أو proxy، فعندئذ ويشير ذلك إلى أنّ حجم حمولة الطلب الذي يرسله تطبيق العميل إلى Apigee أكبر عن الحد المسموح به في Apigee Edge.
  3. تحقَّق من حجم حمولة الطلب كما هو محدّد في الخطوة 1.
    • إذا كان حجم حمولة البيانات أكبر من الحد المسموح به 10 ميغابايت، فهذا هو سبب الخطأ.
    • إذا كان حجم الحمولة< يبلغ الحد المسموح به 10 ميغابايت، فمن الممكن أن يطلب يتم تمرير الحمولة بتنسيق مضغوط. في هذه الحالة، تحقق من الحجم غير المضغوط حمولة البيانات المضغوطة.
  4. يمكنك التحقق مما إذا كان الطلب من العميل قد تم إرساله بتنسيق مضغوط الحجم غير المضغوط أكبر من الحد المسموح به باستخدام أحد العناصر التالية الطرق:

    التتبّع

    للتحقّق من الصحة باستخدام أداة التتبُّع:

    1. إذا سجّلت تتبُّعًا للطلب الذي تعذّر إكماله، يمكنك الرجوع إلى الخطوات الموضّحة بالتفصيل في Trace
      1. تحديد قيمة المتغيّر client.received.content.length
      2. تحقق مما إذا كان الطلب من العميل يتضمن Content-Encoding: العنوان gzip
    2. إذا كانت قيمة المتغيّر client.received.content.length أكبر من 10 ميغابايت، الحد المسموح به، وعنوان الطلب Content-Encoding: gzip فهذا هو سبب هذا الخطأ.

    طلب فعلي

    للتحقّق من الصحة باستخدام الطلب الفعلي:

    1. إذا لم يكن لديك إذن الوصول إلى الطلب الفعلي المقدَّم من تطبيق العميل، انتقِل إلى الحلّ:
    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. إذا كنت مستخدمًا خاصًا في السحابة الإلكترونية، يمكنك استخدام سجلات "معالج الرسائل" لتحديد المعلومات الأساسية حول أخطاء 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

      ويشير ضمنًا إلى أنّ حجم حمولة الطلب أكبر من 10 ميغابايت، كما أنه عمليات طرح Apigee ظهور الخطأ RequestTooLarge عندما يبدأ الحجم في تجاوز الحد الأقصى المسموح به وهو 10 ميغابايت مع رمز خطأ بتنسيق protocol.http.TooBigBody

الدقة

إصلاح الحجم

الخيار #1 [مقترَح]: إصلاح تطبيق العميل لعدم إرسال حجم حمولة أكبر من الحد المسموح به

  1. تحليل السبب الذي يدفع العميل المحدّد لإرسال الطلب أو حجم الحمولة أكثر من المسموح به كما هو موضح في الحدود.

  2. إذا لم يكن مرغوبًا فيه، عدِّل تطبيق العميل بحيث يرسل الطلب أو الحمولة الحجم أقل من الحد المسموح به.

    في المثال الذي ناقشناه أعلاه، يمكنك حل المشكلة بتمرير ملف أصغر حجمًا، لنفترض أنّ حمولة البيانات test5mbfile (بحجم 5 ميغابايت) كما هو موضّح أدناه: 

    curl https://<host>/testtoobigbody -k -X POST -F file=@test5mbfile -v

  3. إذا كان ذلك مرغوبًا وكنت تريد إرسال طلب/حمولة أكثر من الحد المسموح به، انتقِل إلى الخيارات التالية.

نمط عنوان URL الموقَّع

الخيار #2 [مقترَح]: استخدام نمط عناوين URL الموقَّعة ضمن Apigee JavaCallout

بالنسبة إلى الحمولات التي يزيد حجمها عن 10 ميغابايت، تقترح Apigee استخدام نمط عناوين URL مُوقَّعة داخل وسيلة شرح Apigee Java، موضّحة وسيلة شرح Edge: مثال على "منشئ عنوان URL الموقَّع" على GitHub.

البث

الخيار #3 : استخدام البث

إذا كان الخادم الوكيل لواجهة برمجة التطبيقات بحاجة إلى معالجة طلبات و/أو استجابات كبيرة جدًا، يمكنك تفعيل جارٍ البث في Apigee.

CwC

الخيار 4 : استخدام سمة CwC لزيادة حدّ المخزن المؤقت

ويجب استخدام هذا الخيار فقط عندما لا يمكنك استخدام أي من الخيارات المقترحة إذ قد مشكلات في الأداء في حالة زيادة الحجم الافتراضي.

توفّر Apigee سمة CwC التي تسمح بزيادة الحد الأقصى لحجم حمولة الطلبات والاستجابة. للحصول على التفاصيل، يُرجى الرجوع إلى ضبط الحدّ الأقصى لحجم الرسائل على "جهاز التوجيه" أو "معالج الرسائل"

الحدود

تتوقع Apigee ألا يرسل تطبيق العميل وخادم الخلفية أحجام حمولة أكبر من الحد المسموح به كما هو موثق لـ Request/response size في حدود Apigee Edge

  1. إذا كنت مستخدمًا على السحابة الإلكترونية العامّة، سيكون الحدّ الأقصى للطلبات والردّ. تم توثيق حجم الحمولة لـ Request/response size في حدود Apigee Edge
  2. إذا كنت مستخدمًا خاصًا على السحابة الإلكترونية من المحتمل أنّك عدّلت الخيار التلقائي الحد المسموح به لحجم حمولة الطلب والاستجابة (على الرغم من أنه ليس ممارسة موصى بها). يمكنك تحديد الحد الأقصى لحجم حمولة الطلب باتّباع التعليمات الواردة في كيفية التحقّق من الحدّ الأقصى الحالي

كيف يمكن التحقّق من الحدّ الأقصى الحالي؟

يوضِّح هذا القسم كيفية إثبات ملكية الموقع الإلكتروني 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 for Private حجم السحابة الإلكترونية 10 ميغابايت.

إذا كنت لا تزال بحاجة إلى مساعدة من Apigee، يُرجى الانتقال إلى يجب جمع معلومات التشخيص.

يجب جمع معلومات التشخيص

اجمع معلومات التشخيص التالية، ثم تواصَل مع فريق دعم Apigee Edge:

إذا كنت من مستخدمي Cloud Public، يُرجى تقديم المعلومات التالية:

  • اسم المؤسسة
  • اسم البيئة
  • اسم الخادم الوكيل لواجهة برمجة التطبيقات
  • إكمال أمر curl المستخدَم لإعادة إنتاج الخطأ 413
  • ملف تتبُّع طلبات البيانات من واجهة برمجة التطبيقات

إذا كنت من مستخدمي Cloud Private، يُرجى تقديم المعلومات التالية:

  • ظهور رسالة خطأ كاملة للطلبات التي تعذّر تنفيذها
  • اسم المؤسسة
  • اسم البيئة
  • حزمة الخادم الوكيل لواجهة برمجة التطبيقات
  • ملف تتبُّع طلبات البيانات من واجهة برمجة التطبيقات التي تعذّر تنفيذها
  • إكمال أمر 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