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 Public Cloud וב-Edge Private Cloud
גודל המטען הייעודי (payload) של הבקשה חורג מהמגבלה המותרת אחרי הסרת הדחיסה גודל המטען הייעודי (payload) שנשלח בפורמט דחוס על ידי אפליקציית הלקוח כחלק מבקשת HTTP אל Apigee Edge גדול מהמגבלה המותרת כש-Apigee Edge מבצע דחיסה. משתמשים ב-Edge Public Cloud וב-Edge Private Cloud

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

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

API Monitoring

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

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

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

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

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

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

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

    לא דחוס

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

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

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

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

    הקובץ נדחס

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

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

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

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

מעקב

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

  1. מפעילים את trace session ואת אחת מהאפשרויות הבאות:
    • ממתינים להתרחשות השגיאה 413 Request Entity Too Large או
    • אם אתם מצליחים לשחזר את הבעיה, מבצעים את הקריאה ל-API ומשחזרים את השגיאה 413 Request Entity Too Large

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

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

    לא דחוס

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

    חשוב לזכור:

    • Content-Encoding: לא קיים
    • Content-Length: 15360204

    הקובץ נדחס

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

    חשוב לזכור:

    • Content-Encoding: gzip
    • Content-Length: 14969
    • Content-Type: application/x-gzip
  5. עוברים בין השלבים השונים של ה-trace ומאתרים את המקום שבו התרחשה הכשל.

  6. בדרך כלל השגיאה מופיעה בתהליך אחרי השלב Request Received from Client, כמו שמוצג כאן:

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

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

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

    לא דחוס

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

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

    הקובץ נדחס

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

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

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

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

NGINX

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

  1. אם אתם משתמשי Private Cloud, אתם יכולים להשתמש ביומני הגישה של 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-source הם:

    כותרות תגובה ערך
    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.9 K < המגבלה המותרת)

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

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

אבחון

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

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

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

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

רזולוציה

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

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

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

אבחון

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

    מעקב

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

    1. אם צילמתם מעקב אחר הבקשה שנכשלה, תוכלו להיעזר בשלבים שמפורטים במאמרים בנושא מעקב ובנושא
      1. קביעת הערך של המשתנה client.received.content.length
      2. בודקים אם הבקשה מהלקוח הכילה את הכותרת Content-Encoding: gzip
    2. אם הערך של המשתנה client.received.content.length גדול מ-10 MB, שהוא המגבלה המותרת, וגם כותרת הבקשה היא 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 הוא בערך 15 MB והכותרת Content-Encoding היא gzip.

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

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

רזולוציה

תיקון המידה

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

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

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

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

    curl https://<host>/testtoobigbody -k -X POST -F file=@test5mbfile -v
  3. אם רוצים לשלוח בקשה או מטען ייעודי (payload) מעבר למגבלה המותרת, אפשר לעבור לאפשרויות הבאות.

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

אפשרות מספר 2 [מומלצת]: שימוש בתבנית של כתובות URL חתומות ב-JavaCallout של Apigee

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

סטרימינג

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

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

CwC

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

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

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

מגבלות

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

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

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

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

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

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

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

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

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