400 Bad Request – DeדחיסתionFailureAtRequest

מוצג המסמך של Apigee Edge.
עוברים אל מסמכי תיעוד של Apigee X. מידע

תיאור הבעיה

אפליקציית הלקוח מקבלת קוד סטטוס HTTP של 400 Bad Request עם קוד שגיאה messaging.adaptors.http.flow.DecompressionFailureAtRequest כתגובה ל-API שיחות.

הודעת שגיאה

אפליקציית הלקוח מקבלת את קוד התגובה הבא: 

HTTP/1.1 400 Bad Request

בנוסף, יכול להיות שתופיע הודעת שגיאה דומה להודעה שמוצגת בהמשך: 

{
   "fault":{
      "faultstring":"Decompression failure at request",
      "detail":{
         "errorcode":"messaging.adaptors.http.flow.DecompressionFailureAtRequest"
      }
   }
}

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

השגיאה הזו מתקבלת רק אם:

  • הקידוד שצוין בכותרת בקשת HTTP Content-Encoding חוקי ו- שנתמכות ב-Apigee Edge,

    • אבל

  • פורמט המטען הייעודי (Payload) שהלקוח שולח כחלק מבקשת ה-HTTP לא להתאים לפורמט הקידוד שצוין בכותרת Content-Encoding

הסיבה לכך היא ש-Apigee Edge לא מצליחה לפענח את המטען הייעודי (payload) באמצעות הקידוד שצוין, של המטען הייעודי (Payload) אינו בפורמט זהה לזה של הקידוד שצוין הכותרת Content-Encoding.

הנה כמה דוגמאות לערכים נתמכים של Content-Encoding ולאופן השימוש ב-Apigee Edge מצפה שפורמט המטען הייעודי (Payload) יהיה במקרים האלה:

תרחיש קידוד התוכן הפורמט הצפוי של המטען הייעודי (Payload)
קידוד יחיד gzip

פורמט gzip Unix.

צפייה פורמט RFC1952 GZIP.

קידוד יחיד להקטין

בפורמט הזה נעשה שימוש במבנה zlib עם אלגוריתם לדחיסת נתונים.

ראו RFC1950 וגם RFC1951.
קידוד מרובה

קידוד מרובה

לדוגמה, במקרים שבהם הקידוד מתבצע פעמיים, המצב עשוי להיות:

  • gzip, deflate
  • gzip, gzip
  • deflate, gzip
  • להפוך, להקטין, להתרחב
 קידודים מרובים הופעלו במטען הייעודי (payload) בסדר הנתון כפי שהוא מופיע בכותרת.

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

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

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

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

מעקב API

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

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

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

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

  7. צריך לבחור תא עם קוד התקלה messaging.adaptors.http.flow.DecompressionFailureAtRequest בתור מוצגת למטה:

    ( הצגת תמונה גדולה יותר)

  8. מידע על קוד התקלה messaging.adaptors.http.flow.DecompressionFailureAtRequest מוצג כפי שמוצג כאן:

    ( הצגת תמונה גדולה יותר)

  9. לוחצים על הצגת היומנים ומרחיבים את השורה שבה מופיעה השגיאה 400.

    ( הצגת תמונה גדולה יותר)

  10. בחלון יומנים שימו לב לפרטים הבאים:
    • קוד סטטוס: 400
    • מקור התקלה: proxy
    • קוד התקלה: messaging.adaptors.http.flow.DecompressionFailureAtRequest.
  11. אם ל-Fault Source יש את הערך proxy, זה מציין שפורמט המטען הייעודי (payload) של הבקשה לא התאים בקידוד נתמך שמצוין בכותרת Content-Encoding.

כלי המעקב

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

  1. מפעילים את סשן המעקב וגם:
    1. צריך להמתין עד שהשגיאה 400 Bad Request תתרחש, או
    2. אם הצלחתם לשחזר את הבעיה, יש לבצע את הקריאה ל-API ולשחזר 400 Bad Request

  2. מוודאים שהאפשרות Show all FlowInfos מופעלת:

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

  5. בדרך כלל השגיאה תופיע בתהליך מיד אחרי שלב הבקשה התקבלה מהלקוח כפי שמוצג בהמשך:

    ( הצגת תמונה גדולה יותר)

  6. שימו לב לערכי המאפיינים שמופיעים במעקב:

    • שגיאה: Decompression failure at request
    • error.class: com.apigee.rest.framework.BadRequestException
    • error.cause: Not in GZIP format

    התג error.cause מציין שהמטען הייעודי (payload) של הבקשה אינו בפורמט GZIP. המשמעות היא ש-Apigee Edge ציפה שהמטען הייעודי (payload) של הבקשה יהיה בפורמט GZIP כפי שצוין בכותרת Content-Encoding.

  7. קובעים את הערך של כותרת הבקשה Content-Encoding. לשם כך, עוברים לשלב Requestd from Client (בקשה שהתקבלה מהלקוח) כפי שמוצג כאן:

    ( הצגת תמונה גדולה יותר)

    שימו לב שהערך של כותרת הבקשה Content-Encoding הוא אכן ערך gzip.

    נתוני המעקב לדוגמה שלמעלה מראים שהקידוד שצוין בכותרת הבקשה Content-Encoding הוא gzip; עם זאת, המטען הייעודי (Payload) של הבקשה אינו בפורמט GZIP. לכן, Apigee לא יכולה לפתוח את הדחיסה של המטען הייעודי (payload) באמצעות gzip ומחזיר את השגיאה Decompression failure at request.

  8. שימו לב לקוד הסטטוס ולהודעת השגיאה שהוחזרה על ידי Apigee Edge על ידי ניווט

    לשלב התגובה נשלחה ללקוח במעקב, כפי שמוצג בהמשך:

    ( הצגת תמונה גדולה יותר)

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

    • קוד הסטטוס: 400 Bad Request.
    • תוכן השגיאה: {"fault":{"faultstring":"Decompression failure at request","detail":{"errorcode":"messaging.adaptors.http.flow.DecompressionFailureAtRequest"}}}

  9. מנווטים לשלב AX (Analytics Data Recorded) במעקב ולוחצים עליה.

  10. גוללים למטה לקטע פרטי שלב, כותרות של שגיאות ו לקבוע את הערכים של X-Apigee-fault-code ושל X-Apigee-fault-source כפי שמוצג בהמשך:

    ( הצגת תמונה גדולה יותר)

  11. יופיעו הערכים של X-Apigee-fault-code ו-X-Apigee-fault-source. בתור messaging.adaptors.http.flow.DecompressionFailureAtRequest ו policy, שמציין שפורמט המטען הייעודי (payload) של הבקשה לא תאם הקידוד שמצוין בכותרת Content-Encoding.
    כותרות של תשובות ערך
    X-Apigee-fault-code messaging.adaptors.http.flow.DecompressionFailureAtRequest
    X-Apigee-fault-source policy

NGINX

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

  1. אם אתם משתמשים בענן פרטי, תוכלו להשתמש ביומני הגישה ל-NGINX כדי לדעת את המידע העיקרי לגבי שגיאות HTTP 400.

  2. בודקים את יומני הגישה ל-NGINX:

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

    איפה: ORG, ENV ו-PORT# מוחלפים בערכים בפועל.

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

  4. אם מופיעות שגיאות 400 בקוד X-Apigee-fault-code תואם לערך של messaging.adaptors.http.flow.DecompressionFailureAtRequest, לאחר מכן קובעים את הערך של X-Apigee-fault-source.

    דוגמה לשגיאה 400 מיומן הגישה ל-NGINX:

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

    כותרות של תשובות ערך
    X-Apigee-fault-code messaging.adaptors.http.flow.DecompressionFailureAtRequest
    X-Apigee-fault-source policy

הסיבה: פורמט המטען הייעודי (payload) של הבקשה לא תואם לקידוד שצוין בכותרת Content-Encoding

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

אבחון

  1. מגדירים את קוד השגיאה ואת מקור התקלה של השגיאה שזוהתה באמצעות ה-API יומני Monitoring, כלי מעקב או יומני גישה ל-NGINX, כמו שמוסבר ב שלבי האבחון הנפוצים.
  2. אם קוד השגיאה הוא messaging.adaptors.http.flow.DecompressionFailureAtRequest וגם ל-Fault Source יש את הערך policy או proxy, ואז זה מציין שהבקשה שנשלחה על ידי אפליקציית הלקוח מכילה מטען ייעודי (payload) שלא תואם הקידוד הנתמך שצוין בכותרת הבקשה Content-Encoding.

  3. אפשר לקבוע את חוסר ההתאמה כחלק מבקשת ה-HTTP באמצעות אחת מהאפשרויות הבאות אמצעי תשלום:

    הודעת שגיאה

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

    1. אם יש לכם גישה להודעת השגיאה המלאה שהתקבלה מ-Apigee Edge, יש לעיין בfaultstring.

      הודעת שגיאה לדוגמה:

      "faultstring":"Decompression failure at request"
    2. בהודעת השגיאה שלמעלה, מופיע "Decompression failure at request", שמרמז על הבקשה לא ניתן לפרק באמצעות הקידוד שצוין כותרת Content-Encoding.

    Trace

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

    1. קובעים את הערך של כותרת הבקשה Content-Encoding הנכס error.cause באמצעות Trace כפי שמוסבר בשלבי האבחון הנפוצים.

    2. הערכים מהמעקב לדוגמה הם:

      • קידוד תוכן: gzip
      • error.cause: Not in GZIP format

      הערך בכותרת הבקשה Content-Encoding הוא gzip; עם זאת, המטען הייעודי (payload) של הבקשה הוא לא בפורמט GZIP. (כפי שמצוין על ידי error.cause). לכן, Apigee Edge מגיבה 400 Bad Request וקוד השגיאה messaging.adaptors.http.flow.DecompressionFailureAtRequest.

    הבקשה בפועל

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

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

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

    3. אם הערך של הכותרת Content-Encoding נמצא ברשימה של בקידוד נתמך אבל הפורמט של המטען הייעודי (Payload) של הבקשה לא תואם לקידוד שצוין בכותרת Content-Encoding, זאת הסיבה לבעיה.

      בקשה לדוגמה:

      curl -v "http://HOSTALIAS/v1/testgzip" -H "Content-Encoding: gzip" -X POST -d @request_payload.zip

      בקשת הדוגמה שלמעלה שולחת את הערך gzip אל הכותרת Content-Encoding, בקידוד נתמך ב-Apigee Edge. עם זאת, המטען הייעודי (Payload) של הבקשה הקובץ request_payload.zip הוא בפורמט ZIP. לכן, הבקשה נכשל עם קוד הסטטוס 400 Bad Request וקוד השגיאה: messaging.adaptors.http.flow.DecompressionFailureAtRequest.

    יומני מעבד ההודעות

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

    אם אתם משתמשים ב-Private Cloud, תוכלו להשתמש ביומני עיבוד ההודעות. כדי לקבוע את המידע העיקרי לגבי שגיאות HTTP 400.

    1. קובעים את מזהה ההודעה של הבקשה שנכשלה באמצעות API Monitoring, כלי המעקב, או יומני גישה ל-NGINX, כמו שמוסבר בשלבי האבחון הנפוצים.

    2. מחפשים את מזהה ההודעה ביומן מעבד ההודעות:

      /opt/apigee/var/log/edge-message-processor/logs/system.log

    3. יופיע אחד מהחריגים הבאים:

      תרחיש מס' 1

      תרחיש מס' 1: כאשר בקשת API כוללת את הכותרת Content-Encoding: gzip

      2021-07-28 10:21:16,861  NIOThread@0 ERROR HTTP.SERVER -
HTTPServer$Context.onInputException() : Message id:rt-57-1
SSLClientChannel[Accepted: Remote:192.168.199.8:8443
Local:192.168.80.234:44284]@28469 useCount=1 bytesRead=0
bytesWritten=28764 age=2739893ms  lastIO=0ms
isOpen=true.onExceptionRead exception: {}
java.util.zip.ZipException: Not in GZIP format

2021-07-28 10:21:16,862  NIOThread@0 ERROR ADAPTORS.HTTP.FLOW -
AbstractRequestListener.onException() : Request:POST, uri:/test,
message Id:rt-57-1, exception:java.util.zip.ZipException: Not in GZIP format,
context:Context@71ea5ac input=ClientInputChannel(SSLClientChannel[Accepted:
Remote:192.168.199.8:8443 Local:192.168.80.234:44284]@28469 useCount=1
bytesRead=0 bytesWritten=28764 age=2739894ms  lastIO=0ms  isOpen=true)
2021-07-28 10:21:16,862  NIOThread@0 INFO  HTTP.SERVICE -
ExceptionHandler.handleException() :
Exception java.util.zip.ZipException: Not in GZIP format occurred while writing
to channel null
2021-07-28 10:21:16,863  NIOThread@0 INFO  HTTP.SERVICE -
ExceptionHandler.handleException() : Exception trace:
java.util.zip.ZipException: Not in GZIP format

      השורה java.util.zip.ZipException: Not in GZIP format בהודעת השגיאה שלמעלה מציינת שהבקשה המטען הייעודי לא נשלח בפורמט GZIP, אבל Content-Encoding מוגדר כ-gzip. לכן, Apigee Edge זורקת את החריגה מחזירה קוד סטטוס 400 עם קוד שגיאה messaging.adaptors.http.flow.DecompressionFailureAtRequest לאפליקציות לקוח.

      תרחיש מס' 2

      תרחיש מס' 2: כאשר בקשת API כוללת את הכותרת Content-Encoding: deflate

      2021-07-28 15:26:31,893  NIOThread@1 ERROR HTTP.SERVER -
HTTPServer$Context.onInputException() : Message id:rt-47875-1
SSLClientChannel[Accepted: Remote:192.168.199.8:8443
Local:192.168.81.72:45954]@29276 useCount=1 bytesRead=0
bytesWritten=37230 age=3498856ms  lastIO=1ms
isOpen=true.onExceptionRead exception: {}
java.util.zip.ZipException: incorrect header check
                  ….
Caused by: java.util.zip.DataFormatException: incorrect header check
       ..
2021-07-28 15:26:31,894  NIOThread@1 ERROR ADAPTORS.HTTP.FLOW -
AbstractRequestListener.onException() : Request:POST, uri:/test,
message Id:rrt-47875-1, exception:java.util.zip.ZipException:
incorrect header check, context:Context@69b3ac45
input=ClientInputChannel(SSLClientChannel[Accepted:
Remote:192.168.199.8:8443 Local:192.168.81.72:45954]@29276
useCount=1 byt	esRead=0 bytesWritten=37230 age=3498856ms
lastIO=1ms  isOpen=true)

      השורות java.util.zip.ZipException: incorrect header check וגם Caused by: java.util.zip.DataFormatException: incorrect header check בהודעת השגיאה שלמעלה מציינים שהמטען הייעודי (Payload) של הבקשה לא נשלח. הוא לא תואם לקידוד שצוין הכותרת Content-Encoding של deflate. לכן, Apigee Edge זורקת את החריג ומחזירה קוד סטטוס 400 עם קוד השגיאה messaging.adaptors.http.flow.DecompressionFailureAtRequest לאפליקציות לקוח.

רזולוציה

  1. אם אין צורך במטען הייעודי (payload) של הבקשה הדחוסה בתהליך ה-Proxy ל-API ב-Apigee Edge ובשרת הקצה העורפי, לא מעבירים את הכותרת Content-Encoding. אם צריך לדחוס את המטען הייעודי (payload) של הבקשה, עוברים לשלב 2.
  2. צריך לוודא שאפליקציית הלקוח תמיד שולחת את הפרטים הבאים:
    • כל אחד מהתנאים הבאים קידוד נתמך כערך של הכותרת Content-Encoding בקידוד בקשה
    • המטען הייעודי (payload) של הבקשה בפורמט הנתמך ל-Apigee Edge תואם לקידוד הפורמט צוין בכותרת Content-Encoding
  3. בדוגמה שלמעלה, המטען הייעודי (payload) של הבקשה הוא בפורמט ZIP, אבל כותרת הבקשה. מציין את הערך Content-Encoding: gzip. כדי לפתור את הבעיה, אפשר לשלוח את הבקשה הכותרת היא Content-Encoding: gzip והמטען הייעודי (payload) של הבקשה נמצא גם ב-gzip פורמט: 
    curl -v "https://HOSTALIAS/v1/testgzip" -H "Content-Encoding: gzip" -X POST -d @request_payload.gz

מפרט

התגובה של Apigee Edge עם קוד הסטטוס 400 Bad Request עם קוד השגיאה messaging.adaptors.http.flow.DecompressionFailureAtRequest בהתאם ל-RFC הבא מפרטים:

מפרט
RFC 7231, סעיף 6.5.1
RFC 7231, סעיף 3.1.2.2

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

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

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

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

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

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

  • הודעת שגיאה מלאה שנצפתה בבקשות שנכשלו
  • שם הסביבה
  • חבילת API Proxy
  • קובץ מעקב אחר בקשות ה-API

  • יומני גישה ל-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