502 שער שגוי - תגובה 405 ללא כותרת הרשאה

API Monitoring

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

1. מתחברים לממשק המשתמש של Edge בתור משתמש עם תפקיד מתאים.

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

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

5. משרטטים את קוד התקלה מול הזמן.

6. בוחרים תא עם קוד השגיאה protocol.http.Response405WithoutAllowHeader כמו בדוגמה הבאה:

   

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

   

8. לוחצים על הצגת יומנים ומרחיבים אחת מהבקשות שנכשלו כדי לראות מידע נוסף.

   
9. בחלון יומנים, רושמים את הפרטים הבאים:
   • קוד סטטוס: 502
   • מקור התקלה: target
   • קוד שגיאה: protocol.http.Response405WithoutAllowHeader.
10. אם מקור השגיאה הוא target וקוד השגיאה הוא protocol.http.Response405WithoutAllowHeader, המשמעות היא ששרת הקצה העורפי הגיב עם קוד סטטוס 405 Method Not Allowed ללא הכותרת Allow.

כלי המעקב

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

1. מפעילים את trace session ואת אחת מהאפשרויות הבאות:
   • ממתינים להתרחשות השגיאה 502 Bad Gateway, או
   • אם אתם מצליחים לשחזר את הבעיה, מבצעים את הקריאה ל-API כדי לשחזר את השגיאה [מספר השגיאה] 502 Bad Gateway

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

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

5. בדרך כלל השגיאה מופיעה בתהליך אחרי השלב Request sent to target server (הבקשה נשלחה לשרת היעד), כמו שמוצג בהמשך:

   

6. רושמים את ערך השגיאה מהמעקב.

   בדוגמה שלמעלה של רצף הודעות השגיאה, השגיאה מוצגת כ-Received 405 Response without Allow Header. השגיאה הזו מופקת על ידי Apigee אחרי שהבקשה נשלחה לשרת הקצה העורפי, ולכן היא מציינת ששרת הקצה העורפי שלח את קוד סטטוס התגובה 405 בלי הכותרת Allow.

7. עוברים לשלב AX (נתוני Analytics שתועדו) בנתוני המעקב ולוחצים עליו.

8. גוללים למטה לקטע Error / Response Headers (שגיאה / כותרות תגובה) בחלונית Phase Details (פרטי השלב) וקובעים את הערכים של X-Apigee-fault-code (קוד תקלה של Apigee) ו-X-Apigee-fault-source (מקור התקלה של Apigee) כמו שמוצג בהמשך:

   
9. הערכים של X-Apigee-fault-code ו-X-Apigee-fault-source יהיו protocol.http.Response405WithoutAllowHeader ו-target בהתאמה, מה שמצביע על כך שהשגיאה הזו נגרמת כי ה-backend שלח את קוד סטטוס התגובה 405 ללא הכותרת Allow.

   כותרות תגובה	ערך
   X-Apigee-fault-code	protocol.http.Response405WithoutAllowHeader
   X-Apigee-fault-source	target

NGINX

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

1. אם אתם משתמשים ב-Private Cloud, אתם יכולים להשתמש ביומני הגישה של NGINX כדי לקבל את פרטי המפתח לגבי שגיאות HTTP 502.

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

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

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

3. מחפשים אם יש שגיאות 502 עם קוד השגיאה protocol.http.Response405WithoutAllowHeader במהלך פרק זמן מסוים (אם הבעיה התרחשה בעבר) או אם יש בקשות שעדיין נכשלות עם קוד השגיאה 502.

4. אם מצאתם שגיאות 502 עם X-Apigee-fault-code שתואם לערך של protocol.http.Response405WithoutAllowHeader, צריך לקבוע את הערך של X-Apigee-fault-source.

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

   

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

   כותרות תגובה	ערך
   X-Apigee-fault-code	protocol.http.Response405WithoutAllowHeader
   X-Apigee-fault-source	target

שרת עורפי

אפשרות 1: מתקנים את שרת הקצה העורפי כך שישלח את קוד המצב 405 עם כותרת Allow:

1. צריך לוודא ששרת הקצה העורפי תמיד פועל בהתאם למפרט RFC 7231, section 6.5.5: 405 Method Not Allowed ושולח עם קוד הסטטוס 405 על ידי הכללת רשימת השיטות שמותרות כחלק מכותרת Allow, כמו שמוצג בהמשך:

   Allow: HTTP_METHODS

2. לדוגמה, אם שרת הקצה העורפי מאפשר שימוש בשיטות GET, POST ו-HEAD, צריך לוודא שהכותרת Allow מכילה אותן באופן הבא:

   Allow: GET, POST, HEAD

טיפול בשגיאות

אפשרות 2: שימוש בטיפול בשגיאות כדי לשלוח קוד סטטוס 405 עם כותרת Allow משרת ה-proxy של ה-API:

אם שרת הקצה העורפי מחזיר את קוד הסטטוס 405 ללא הכותרת Allow, אפשר להשתמש בטיפול בשגיאות כדי להחזיר את קוד הסטטוס 405 ואת הכותרת Allow מ-proxy ל-API באופן הבא:

1. יוצרים מדיניות כמו AssignMessage policy או RaiseFault policy ומגדירים את קוד הסטטוס ל-405 עם כותרת Allow והודעה מותאמת אישית.

   מדיניות לדוגמה של AssignMessage לשליחת 405 עם כותרת Allow:

   <AssignMessage async="false" continueOnError="false" enabled="true" name="AM-405WithAllowHeader">
       <DisplayName>AM-405WithAllowHeader</DisplayName>
       <Set>
           <Payload contentType="application/json">{"Specified method is not allowed. Please use one of the methods mentioned in the Allow header."}</Payload>
           <StatusCode>405</StatusCode>
           <ReasonPhrase>Method Not Allowed</ReasonPhrase>
       </Set>
       <Add>
           <Headers>
               <Header name="Allow">GET, POST, HEAD</Header>
           </Headers>
       </Add>
       <IgnoreUnresolvedVariables>true</IgnoreUnresolvedVariables>
       <AssignTo createNew="false" transport="http" type="request"/>
   </AssignMessage>

2. יוצרים FaultRule ב-TargetEndpoint שמפעיל את המדיניות כשמתקבלת השגיאה 502 עם קוד השגיאה protocol.http.Response405WithoutAllowHeader.

   תצורה לדוגמה של TargetEndpoint עם FaultRule:

   <TargetEndpoint name="default">
   ...
       <FaultRules>
          <FaultRule name="405WithoutAllowHeader">
               <Step>
                   <Name>AM-405WithAllowHeader</Name>
               </Step>
               <Condition>(fault.name = "Response405WithoutAllowHeader")</Condition>
           </FaultRule>
       </FaultRules>

3. שומרים את השינויים האלה בגרסה חדשה של ה-proxy ל-API ופורסים את הגרסה.
4. מבצעים את הקריאות ל-API ומוודאים שמקבלים את קוד הסטטוס 405 עם הכותרת Allow.

הגדרת נכס

אפשרות 3: הגדרת המאפיין במעבד ההודעות כדי למנוע מ-Apigee Edge להחזיר שגיאת 502

1. אם אתם משתמשים ב-Private Cloud, אתם יכולים לעדכן את המאפיין HTTP.ignore.allow_header.for.405 ל-true כדי למנוע מ-Apigee Edge להציג שגיאת 502, גם אם שרת הקצה העורפי מגיב עם קוד סטטוס 405 בלי הכותרת Allow. לשם כך, אפשר להיעזר במדריך הגדרת התעלמות מהכותרת allow עבור מאפיין 405 במעבדי הודעות.
2. אם אתם משתמשים בענן ציבורי, אתם יכולים לפנות אל התמיכה של Apigee Edge.