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"
      }
   }
}

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

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

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

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

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

אפשר להשתמש באחד מהכלים/הטכניקות הבאים כדי לאבחן את השגיאה הזו:

מעקב באמצעות API

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

  1. נכנסים לממשק המשתמש של Apigee Edge בתור משתמשים עם תפקיד מתאים.

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

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

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

  8. מידע על קוד התקלה protocol.http.TooBigBody מוצג באופן הבא:

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

    לא דחוס

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

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

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

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

    דחוס

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

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

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

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

נתוני מעקב

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

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

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

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

    לא דחוס

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

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

    • קידוד התוכן: לא קיים
    • Content-Length: 15360204

    דחוס

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

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

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

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

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

    לא דחוס

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

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

    דחוס

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

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

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

    חרגת ממגבלת הגודל בזמן ביטול הדחיסה

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

    כותרות תגובה Value
    X-Apigee-fault-code protocol.http.TooBigBody
    X-Apigee-fault-sourc policy

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

    דחוס

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

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

    כותרות תגובה Value
    X-Apigee-fault-code protocol.http.TooBigBody
    X-Apigee-fault-source policy

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

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

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

אבחון

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

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

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

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

רזולוציה

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

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

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

אבחון

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

    נתוני מעקב

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

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

    בקשה בפועל

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

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

      2. צריך לבדוק אם הגודל הלא דחוס של המטען הייעודי חורג מהמגבלה המותרת ב-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

      ניתן להסיק מכך שגודל המטען הייעודי של הבקשה גדול מ-10MB ו-Apigee מקפץ את השגיאה RequestTooLarge כשהגודל מתחיל לחרוג מהמגבלה של 10MB עם קוד שגיאה כ-protocol.http.TooBigBody

רזולוציה

תיקון הגודל

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

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

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

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

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

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

תבנית של כתובת אתר חתומה

אפשרות מס' 2 [מומלץ]: שימוש בדפוס כתובות URL חתומות בתוך Apigee JavaCallout

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

סטרימינג

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

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

CwC

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

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

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

מגבלות

Apigee מצפה שאפליקציית הלקוח ושרת הקצה העורפי לא ישלחו מטענים ייעודיים שגדולים מהמגבלה המותרת, כפי שמתואר עבור Request/response size ב-Apigee Edge Limits.

  1. אם אתם משתמשים ב-Public Cloud, הגודל המקסימלי של המטען הייעודי (payload) של בקשות והיענות, מתועד עבור Request/response size ב-Apigee Edge Limits.
  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, עליכם לספק את הפרטים הבאים:

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

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

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