413 Request Entity גדול מדי – ToBigBody

מוצג המסמך של 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"
      }
   }
}

גורמים אפשריים

שגיאה זו מתרחשת אם גודל המטען הייעודי (payload) שנשלח על ידי אפליקציית הלקוח ל-Apigee Edge כחלק בקשת ה-HTTP גדולה מהמגבלה המותרת ב-Apigee Edge .

הנה הסיבות האפשריות לשגיאה הזו :

סיבה תיאור הוראות לפתרון בעיות עבור
גודל המטען הייעודי (payload) של הבקשה חורג מהמגבלה המותרת גודל המטען הייעודי (Payload) שנשלח על ידי אפליקציית הלקוח כחלק מבקשת HTTP ל-Apigee Edge הוא חרגת מהמגבלה המותרת ב-Apigee Edge. משתמשי Edge בענן הציבורי והפרטי
גודל המטען הייעודי של הבקשה חורג מהמגבלה המותרת אחרי שחרור דחיסה גודל המטען הייעודי (Payload) שנשלח בפורמט דחוס על ידי אפליקציית הלקוח כחלק מ-HTTP הבקשה ל-Apigee Edge חורגת מהמגבלה המותרת כשמבטלים את הדחיסה על ידי Apigee Edge. משתמשי Edge בענן הציבורי והפרטי

שלבי אבחון נפוצים

יש להשתמש באחד מהכלים או השיטות הבאים כדי לאבחן את השגיאה:

מעקב API

כדי לאבחן את השגיאה באמצעות API Monitoring:

  1. נכנסים ל-Apigee Edge UI כמשתמש עם התפקיד המתאים.

  2. צריך לעבור לארגון שבו רוצים לחקור את הבעיה

  3. מנווטים אל ניתוח > מעקב API > לחקור את הדף.
  4. בוחרים את מסגרת הזמן הספציפית שבה הבחנתם בשגיאות.
  5. אפשר לבחור במסנן Proxy כדי לצמצם את קוד השגיאה.
  6. הציגו את קוד התקלה ביחס ל-Time.

  7. צריך לבחור תא עם קוד השגיאה protocol.http.TooBigBody וגם קוד הסטטוס 413כפי שמוצג בהמשך:

  8. מידע על קוד התקלה protocol.http.TooBigBody מוצג כך למטה:

  9. לוחצים על הצגת היומנים ומרחיבים את השורה של הבקשה שנכשלה. לאחר מכן מתוך בחלון יומנים. שימו לב לפרטים הבאים :

    לא דחוס

    תרחיש מס' 1: 'בקשת מטען ייעודי (payload)' נשלח בפורמט לא דחוס

    בחלון היומנים, שימו לב לפרטים הבאים:

    • קוד סטטוס: 413
    • מקור התקלה: proxy
    • קוד התקלה: protocol.http.TooBigBody.
    • אורך הבקשה(בייטים): 15360440 (כ-15MB)

    אם ל-Fault Source יש את הערך proxy , זה Fault Code מכיל את הערך protocol.http.TooBigBody ו-Request Length גדול מ-10MB, אז הוא מציין שבבקשת ה-HTTP מהלקוח יש גודל המטען הייעודי (payload) של הבקשה גדול מהמגבלה המותרת ב-Apigee.

    דחוס

    תרחיש מס' 2: 'בקשת מטען ייעודי (payload)' שנשלח בפורמט דחוס

    בחלון יומנים שימו לב לפרטים הבאים:

    • קוד סטטוס: 413
    • מקור התקלה: proxy
    • קוד התקלה: protocol.http.TooBigBody.
    • אורך הבקשה(בייטים): 15264 (~15kB)

    אם ל-Fault Source יש את הערך proxy , זה Fault Code מכיל את הערך protocol.http.TooBigBody, ו-Request Length הוא קטנה מ-10MB, אז היא מציינת שבקשת ה-HTTP מהלקוח כוללת גודל המטען הייעודי (payload) של הבקשה נמוך מהמגבלה המותרת בפורמט הדחוס, אבל גודל המטען הייעודי (Payload) גדול מהמגבלה המותרת כשהוא לא דחוס על ידי Apigee.

Trace

כדי לאבחן את השגיאה באמצעות כלי המעקב:

  1. להפעיל את סשן המעקב ואז
    • יש להמתין עד שהשגיאה 413 Request Entity Too Large תתבצע, או
    • אם הצלחתם לשחזר את הבעיה, יש לבצע את הקריאה ל-API ולשחזר שגיאה אחת (413 Request Entity Too Large)

  2. מוודאים שהאפשרות הצגת כל פרטי הזרימה מופעלת.

  3. בוחרים אחת מהבקשות שנכשלו ובודקים את המעקב.
  4. עוברים לשלב Requestd from Client (בקשה שהתקבלה מהלקוח).

    לא דחוס

    תרחיש מס' 1: 'בקשת מטען ייעודי (payload)' נשלח בפורמט לא דחוס

    שימו לב לפרטים הבאים:

    • קידוד תוכן: לא קיים
    • אורך התוכן: 15360204

    דחוס

    תרחיש מס' 2: 'בקשת מטען ייעודי (payload)' שנשלח בפורמט דחוס

    שימו לב לפרטים הבאים:

    • קידוד תוכן: gzip
    • אורך התוכן: 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 (נתוני Analytics מתועדים) במעקב ולוחצים עליו.

  10. בקטע פרטי שלב, גוללים למטה אל משתנים שנקראים.

  11. קובעים את הערך של המשתנה client.received.content.length, שמציין את:
    • הגודל בפועל של המטען הייעודי (payload) של הבקשה כשהוא נשלח בפורמט לא דחוס
    • גודל המטען הייעודי (payload) של הבקשה לאחר ביטול הדחיסה על ידי Apigee, כשהמטען הייעודי (Payload) הוא נשלח בפורמט דחוס. הוא תמיד יהיה זהה לערך של המגבלה (10MB) בתרחיש הזה.

    לא דחוס

    תרחיש מס' 1: בקשת מטען ייעודי (payload) בפורמט לא דחוס

    המשתנה client.received.content.length: 15360204

    דחוס

    תרחיש מס' 2: בקשת מטען ייעודי (payload) בפורמט דחוס

    המשתנה client.received.content.length: 10489856

  12. הטבלה הבאה מסבירה למה השגיאה 413 מוחזרת על ידי Apigee שני התרחישים שמבוססים על הערך של client.received.content.length variable:
    תרחיש הערך של client.received.content.length הסיבה לכשל
    בקשת מטען ייעודי (payload) בפורמט לא דחוס כ-15MB גודל > מוגבלת ל-10MB.
    בקשת מטען ייעודי (payload) בפורמט דחוס ~10 MB

    חריגה ממגבלת הגודל לאחר שחרור הדחיסה

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 : בקשת גודל מטען ייעודי (payload) בפורמט לא דחוס

    הרשומה לדוגמה שלמעלה מיומן הגישה ל-NGINX כוללת את הערכים הבאים עבור X-Apigee-fault-code ו-X-Apigee-fault-code

    כותרות של תשובות ערך
    X-Apigee-fault-code protocol.http.TooBigBody
    X-Apigee-fault-sourc policy

    חשוב לשים לב לאורך הבקשה: 15360440 (14.6 MB > המגבלה המותרת)

    דחוס

    תרחיש מס' 2 : בקשת גודל מטען ייעודי (payload) בפורמט דחוס

    הרשומה לדוגמה שלמעלה מיומן הגישה ל-NGINX כוללת את הערכים הבאים עבור X-Apigee-fault-code ו-X-Apigee-fault-source:

    כותרות של תשובות ערך
    X-Apigee-fault-code protocol.http.TooBigBody
    X-Apigee-fault-source policy

    חשוב לשים לב לאורך הבקשה: 15264 (14.9K < המגבלה המותרת)

    בתרחיש הזה, Apigee Edge מחזירה 413 על אף הערך אורך הבקשה נמוך מהמגבלה המותרת כי הבקשה עשויה נשלחו בפורמט דחוס וגודל המטען הייעודי (Payload) חורג מוגבלת בעת ביטול הדחיסה על ידי Apigee Edge.

הסיבה: גודל המטען הייעודי (Payload) של הבקשה חורג מהמגבלה המותרת

אבחון

  1. מגדירים את fault Code, מקור התקלה וגודל מטען ייעודי (payload) של בקשה בשביל שגיאה שזוהתה באמצעות יומני API Monitoring, Trace Tool או יומני גישה ל-NGINX, כפי שמוסבר ב- שלבי אבחון נפוצים בתרחיש מס' 1 (לא דחוס).
  2. אם מקור התקלה מכיל את הערך policy או proxy, הערך הזה מציין שגודל המטען הייעודי (payload) של הבקשה שנשלח על ידי אפליקציית הלקוח ל-Apigee גדול מ- המגבלה המותרת ב-Apigee Edge.
  3. מאמתים את גודל המטען הייעודי (payload) של הבקשה כפי שנקבע בשלב 1.
  4. אפשר גם לאמת אם גודל המטען הייעודי (payload) של הבקשה הוא אכן > המגבלה של 10 MB מותרת של בדיקת הבקשה בפועל באמצעות השלבים הבאים:
    1. אם אין לכם גישה לבקשה שנשלחה בפועל על ידי אפליקציית הלקוח, עוברים אל רזולוציה.
    2. אם יש לכם גישה לבקשה שנשלחה בפועל על ידי אפליקציית הלקוח, בצעו את את השלבים הבאים:
      1. צריך לאמת את גודל המטען הייעודי (Payload) שמועבר בבקשה.
      2. אם גודל המטען הייעודי (Payload) גדול מ- המותרת ב-Apigee Edge, אז זו הסיבה לבעיה.

        3. בקשה לדוגמה:

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

        במקרה שתיארנו קודם, הקובץ test15mbfile הוא בגודל של כ-15MB. אם משתמשים בלקוח אחר, מקבלים את יומני הלקוח כדי לבדוק מה גודל המטען הייעודי שנשלח.

רזולוציה

עוברים אל רזולוציה.

הסיבה: גודל המטען הייעודי של הבקשה חורג מהמגבלה המותרת אחרי ביטול הדחיסה

אם המטען הייעודי (Payload) של הבקשה נשלח בפורמט דחוס וכותרת הבקשה. השדה Content-Encoding מוגדר ל-gzip, Apigee מבטל את הדחיסה של הבקשה מטען ייעודי (payload). בתהליך ביטול הדחיסה, אם גודל המטען הייעודי (payloade) גדול יותר ב-Apigee מ-10MB, המגבלה המותרת, ואז מפסיק שחרור דחיסה נוסף ומגיב מיד עם 413 Request Entity Too Large עם קוד שגיאה protocol.http.TooBigBody

אבחון

  1. מגדירים את קוד השגיאה,מקור התקלה, וגודל המטען הייעודי (Payload) של הבקשה. לשגיאה שזוהתה באמצעות יומני API Monitoring, Trace Tool או NGINX Access, כמו שמוסבר שלבי האבחון הנפוצים בתרחיש מס' 2 (דחוס).
  2. אם ל-Fault Source יש את הערך policy או proxy, מציין שגודל המטען הייעודי (payload) של הבקשה שנשלח על ידי אפליקציית הלקוח ל-Apigee גדול יותר מהמגבלה המותרת ב-Apigee Edge.
  3. מאמתים את גודל המטען הייעודי (payload) של הבקשה כפי שנקבע בשלב 1.
    • אם גודל המטען הייעודי (Payload) > מגבלת הגודל של 10 MB, אז זו הסיבה לשגיאה.
    • אם גודל המטען הייעודי < מגבלת הגודל של 10 MB, אז יכול להיות שהבקשה המטען הייעודי מועבר בפורמט דחוס. במקרה כזה, צריך לבדוק את הגודל הלא דחוס של מטען ייעודי (payload) של בקשה דחוסה.
  4. אפשר לבדוק אם הבקשה מהלקוח נשלחה בפורמט דחוס, הגודל הלא דחוס היה גדול מהמגבלה המותרת באמצעות אחד מהדברים הבאים אמצעי תשלום:

    Trace

    כדי לאמת באמצעות כלי המעקב:

    1. אם תיעדתם מעקב אחר הבקשה שנכשלה, עיינו בשלבים המפורטים ב Trace ו-
      1. קובעים את הערך של המשתנה client.received.content.length
      2. בודקים אם הבקשה מהלקוח מכילה את הרכיב קידוד תוכן: כותרת gzip
    2. אם הערך של המשתנה client.received.content.length גדול מה- 10MB, המגבלה המותרת וכותרת הבקשה Content-Encoding: gzip, זו הסיבה לשגיאה.

    הבקשה בפועל

    כדי לאמת באמצעות הבקשה עצמה:

    1. אם אין לכם גישה לבקשה שנשלחה בפועל על ידי אפליקציית הלקוח, עוברים אל רזולוציה.
    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 הוא כ-15MB הכותרת Content-Encoding היא gzip.

        אם משתמשים בלקוח אחר, צריך לבדוק את יומני הלקוח כדי לבדוק את גודל המטען הייעודי (payload) נשלחת ואם הכותרת 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. בתהליך של ביטול הדחיסה, ברגע שמעבד ההודעות קובע את הסכום הכולל הערך שנקרא 'בייטים' הוא > בגודל 10MB, היא עוצרת ומדפיסה את השורה הבאה: 
      Message is too large.  TotalRead 10489856 chunkCount 2570

      הוא רומז שגודל המטען הייעודי (Payload) של הבקשה גדול מ-10MB וכתוצאה מכך השפעות של Apigee השגיאה RequestTooLarge כשהגודל מתחיל לחרוג מהמגבלה של 10MB עם קוד תקלות: protocol.http.TooBigBody

רזולוציה

תיקון הגודל

אפשרות מס' 1 [מומלץ]: לתקן את אפליקציית הלקוח כך שלא תשלח גודל מטען ייעודי (payload) שגדול יותר מגבלה מותרת

  1. ניתוח הסיבה לכך שהלקוח הספציפי שולח בקשה או גודל מטען ייעודי (payload) גדול מהמותר כפי שמוגדר בקטע מגבלות.

  2. אם לא רוצים לעשות זאת, יש לשנות את אפליקציית הלקוח כך שהיא תשלח בקשה או מטען ייעודי (payload) הגודל קטן מהמגבלה המותרת.

    בדוגמה שלמעלה, ניתן לפתור את הבעיה על ידי העברת קובץ קטן יותר, נניח שהמטען הייעודי (payload) של test5mbfile (בגודל של 5 MB) כמו שמוצג בהמשך: 

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

  3. אם זה מתאים וברצונך לשלוח בקשה/מטען ייעודי (payload) שחורגים מהמגבלה המותרת, עוברים אל את האפשרויות הבאות.

תבנית כתובת URL חתומה

אפשרות מס' 2 [מומלצת]: שימוש בתבנית של כתובות URL חתומות ביתרונות מרכזיים של Apigee Java

למטענים ייעודיים (payloads) שגדולים מ-10MB, ב-Apigee מומלץ להשתמש בתבנית של כתובות URL חתומות בתוך Apigee JavaCallout, איור דוגמה ל-Edge Callout: מחולל כתובת URL חתומה ב-GitHub.

סטרימינג

אפשרות מס' 3 : שימוש בסטרימינג

אם שרת ה-proxy ל-API צריך לטפל בבקשות או בתשובות גדולות מאוד, אפשר להפעיל את האפשרות הזו. סטרימינג ב-Apigee.

CwC

אפשרות מס' 4 : שימוש בנכס CwC כדי להגדיל את מאגר הנתונים הזמני

יש להשתמש באפשרות זו רק כאשר אינך יכול להשתמש באף אחת מהאפשרויות המומלצות, מכיוון שייתכנו עשויות להיות בעיות בביצועים אם גודל ברירת המחדל מוגדל.

Apigee מספקת CwC שמאפשרת להגדיל את מגבלת הגודל של המטען הייעודי (payload) של הבקשה והתשובה. פרטים נוספים זמינים הגדרת מגבלת גודל ההודעות בנתב או במעבד ההודעות

מגבלות

Apigee מצפה שאפליקציית הלקוח ושרת הקצה העורפי לא ישלחו גדלים של מטען ייעודי (payload) שגדולים מ- המגבלה המותרת לפי תיעוד של Request/response size ב- מגבלות Apigee Edge.

  1. אם אתם משתמשים בענן הציבורי, המגבלה המקסימלית של בקשות ותגובה גודל המטען הייעודי (Payload) מתועד עבור Request/response size ב- מגבלות Apigee Edge.
  2. אם אתם משתמשים בענן פרטי , יכול להיות ששיניתם את ברירת המחדל מגבלת גודל המטען הייעודי (payload) של הבקשות והתשובות (למרות שלא מומלץ לעשות זאת). כדי לקבוע את מגבלת הגודל המקסימלי של מטען ייעודי (payload) של בקשות, צריך לפעול לפי ההוראות הבאות: איך בודקים את המגבלה הנוכחית

איך בודקים את המגבלה הנוכחית?

בקטע הזה מוסבר איך לאמת שהנכס 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.

    מציינת שהמגבלה של גודל המטען הייעודי (payload) של הבקשה מוגדרת ב-Apigee לחשבונות פרטיים גודל הענן הוא 10MB.

אם עדיין דרושה לך עזרה מהתמיכה של Apigee, אפשר לעבור אל חובה לאסוף את פרטי האבחון.

חובה לאסוף פרטי אבחון

אוספים את פרטי האבחון הבאים ופונים לתמיכה של Apigee Edge:

אם אתם משתמשים ב-Public Cloud, עליכם לספק את הפרטים הבאים:

  • שם הארגון
  • שם הסביבה
  • שם ה-API של ה-Proxy
  • צריך להשלים את פקודת ה-curl שמשמשת לשחזור השגיאה 413
  • קובץ מעקב אחר בקשות ה-API

אם אתם משתמשים בענן פרטי, עליכם לספק את הפרטים הבאים:

  • הודעת שגיאה מלאה שנצפתה בבקשות שנכשלו
  • שם הארגון
  • שם הסביבה
  • חבילת API Proxy
  • קובץ מעקב לבקשות ה-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