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 العام والخاص على السحابة الإلكترونية
يتجاوز حجم حمولة الطلب الحدّ المسموح به بعد فك الضغط إنّ حجم الحمولة الذي تم إرساله بتنسيق مضغوط بواسطة تطبيق العميل كجزء من طلب HTTP إلى Apigee Edge يتجاوز الحدّ المسموح به عند فك ضغطه بواسطة Apigee Edge. مستخدمو Edge العام والخاص على السحابة الإلكترونية

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

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

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

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

  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 ميغابايت، يشير ذلك إلى أنّ حجم حمولة الطلب المقدّم من العميل أكبر من الحد المسموح به في 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: طلب حمولة البيانات في نموذج غير مضغوط

    دوِّن المعلومات التالية:

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

    مضغوط

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

    دوِّن المعلومات التالية:

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

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

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

  8. انتقِل إلى الردّ المُرسَل إلى العميل ودوِّن قيم الخطأ من تقرير التتبّع. يوضِّح تتبُّع العيّنة أدناه:

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

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

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

    غير مضغوط

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

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

    مضغوط

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

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

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

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

NGINX

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

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

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

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

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

    غير مضغوط

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

    التتبّع

    لإثبات الملكية باستخدام أداة التتبُّع:

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

    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 JavaCallout، وهو موضّح في مثال وسيلة شرح Edge: أداة إنشاء عناوين URL الموقَّعة على GitHub.

بالوضعَين الأفقي والعمودي

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

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

CwC

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

يجب عدم استخدام هذا الخيار إلا عندما لا تتمكّن من استخدام أيٍّ من الخيارات المقترَحة، لأنّه قد تكون هناك مشاكل في الأداء في حال زيادة الحجم التلقائي.

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

الحدود المسموح بها

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

  1. إذا كنت من مستخدمي Public Cloud، يكون الحد الأقصى لحجم حمولة الطلب والاستجابة موثّقًا للسمة 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 لخدمات السحابة الإلكترونية الخاصة هو 10 ميغابايت.

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

ضرورة جمع معلومات التشخيص

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

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

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

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

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