502 Bad Gateway - پاسخ 405 بدون Allow Header

نظارت بر API

برای تشخیص خطا با استفاده از مانیتورینگ API:

1. به عنوان کاربری با نقش مناسب، وارد رابط کاربری Edge شوید.

2. به سازمانی که می‌خواهید مشکل را در آن بررسی کنید، مراجعه کنید.

   
3. به صفحه Analyze > API Monitoring > Investigate بروید.
4. بازه زمانی خاصی را که در آن خطاها را مشاهده کرده‌اید، انتخاب کنید.

5. رسم کد خطا در مقابل زمان .

6. سلولی را انتخاب کنید که کد خطا protocol.http.Response405WithoutAllowHeader مانند تصویر زیر داشته باشد:

   

7. اطلاعات مربوط به کد خطا protocol.http.Response405WithoutAllowHeader مطابق شکل زیر نمایش داده می‌شود:

   

8. برای مشاهده اطلاعات بیشتر، روی «مشاهده گزارش‌ها» کلیک کنید و یکی از درخواست‌های ناموفق را باز کنید.

   
9. از پنجره Logs ، جزئیات زیر را یادداشت کنید:
   • کد وضعیت: 502
   • منبع خطا: target
   • کد خطا: protocol.http.Response405WithoutAllowHeader .
10. اگر منبع خطا target و کد خطا protocol.http.Response405WithoutAllowHeader باشد، نشان می‌دهد که سرور backend با کد وضعیت 405 Method Not Allowed بدون هدر Allow پاسخ داده است.

ابزار ردیابی

برای تشخیص خطا با استفاده از ابزار Trace:

1. جلسه ردیابی را فعال کنید و یا
   • منتظر بمانید تا خطای 502 Bad Gateway رخ دهد، یا
   • اگر می‌توانید مشکل را دوباره ایجاد کنید، فراخوانی API را برای ایجاد مشکل انجام دهید - خطای 502 Bad Gateway

2. مطمئن شوید که گزینه‌ی Show all FlowInfos فعال است:

   
3. یکی از درخواست‌های ناموفق را انتخاب کنید و مسیر پیگیری را بررسی کنید.
4. مراحل مختلف ردیابی را طی کنید و محل وقوع خرابی را پیدا کنید.

5. معمولاً خطا را در جریانی پس از ارسال درخواست به سرور هدف، مطابق شکل زیر، مشاهده خواهید کرد:

   

6. مقدار خطا را از ردیابی یادداشت کنید.

   ردیابی نمونه بالا، خطا را با عنوان Received 405 Response without Allow Header نشان می‌دهد. از آنجایی که این خطا توسط Apigee پس از ارسال درخواست به سرور backend ایجاد شده است، نشان می‌دهد که سرور backend کد وضعیت پاسخ 405 را بدون هدر Allow ارسال کرده است.

7. در مسیر ردیابی، به مرحله AX (داده‌های تحلیلی ثبت‌شده) بروید و روی آن کلیک کنید.

8. در پنل Phase Details به پایین اسکرول کنید تا به بخش Error / Response Headers برسید و مقادیر X-Apigee-fault-code و X-Apigee-fault-source را مطابق شکل زیر تعیین کنید:

   
9. مقادیر X-Apigee-fault-code و X-Apigee-fault-source را به ترتیب به صورت protocol.http.Response405WithoutAllowHeader و target مشاهده خواهید کرد که نشان می‌دهد این خطا به دلیل ارسال کد وضعیت پاسخ 405 توسط backend بدون هدر Allow ایجاد شده است.

   هدرهای پاسخ	ارزش
   کد خطای X-Apigee	protocol.http.Response405WithoutAllowHeader
   منبع گسل X-Apigee	target

انجینکس

برای تشخیص خطا با استفاده از گزارش‌های دسترسی 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 را تعیین کنید.

   نمونه خطای ۵۰۲ از لاگ دسترسی NGINX:

   

   ورودی نمونه بالا از لاگ دسترسی NGINX دارای مقادیر زیر برای X-Apigee- fault-code و X-Apigee-fault-source است:

   هدرهای پاسخ	ارزش
   کد خطای X-Apigee	protocol.http.Response405WithoutAllowHeader
   منبع گسل X-Apigee	target

سرور بک‌اند

گزینه شماره ۱: تنظیم سرور Backend برای ارسال کد وضعیت ۴۰۵ با هدر Allow:

1. اطمینان حاصل کنید که سرور backend همیشه به مشخصات RFC 7231، بخش 6.5.5: 405 Method Not Allowed پایبند است و با درج لیست روش‌هایی که به عنوان بخشی از سربرگ Allow مجاز هستند، مطابق شکل زیر، کد وضعیت 405 را ارسال می‌کند:

   Allow: HTTP_METHODS

2. برای مثال، اگر سرور backend شما متدهای GET ، POST و HEAD را مجاز می‌داند، باید مطمئن شوید که سرآیند Allow شامل آنها به شرح زیر باشد:

   Allow: GET, POST, HEAD

مدیریت خطا

گزینه شماره ۲: استفاده از مدیریت خطا برای ارسال کد وضعیت ۴۰۵ به همراه هدر Allow از پروکسی API شما:

اگر سرور backend کد وضعیت 405 را بدون هدر Allow برگرداند، می‌توانید از مدیریت خطا برای پاسخ دادن با کد وضعیت 405 و هدر Allow از پروکسی API خود به شرح زیر استفاده کنید:

1. یک پالیسی مانند پالیسی AssignMessage یا پالیسی RaiseFault ایجاد کنید و کد وضعیت را روی 405 با هدر Allow و یک پیام سفارشی تنظیم کنید.

   نمونه سیاست AssignMessage برای ارسال خطای ۴۰۵ با هدر 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. این تغییرات را در یک نسخه جدید از پروکسی API خود ذخیره کنید و نسخه را مستقر کنید.
4. فراخوانی‌های API را انجام دهید و با استفاده از هدر Allow تأیید کنید که کد وضعیت 405 را دریافت می‌کنید.

پیکربندی ویژگی

گزینه شماره ۳: پیکربندی ویژگی در پردازشگر پیام برای جلوگیری از بازگشت خطای ۵۰۲ توسط Apigee Edge

1. اگر شما یک کاربر Private Cloud هستید، می‌توانید ویژگی HTTP.ignore.allow_header.for.405 به true به‌روزرسانی کنید تا از ایجاد خطای 502 Apigee Edge جلوگیری شود، حتی اگر سرور backend با کد وضعیت 405 بدون هدر Allow با استفاده از راهنمای نحوه‌ی پیکربندی: پیکربندی هدر ignore allow برای ویژگی ۴۰۵ در Message Processors پاسخ دهد.
2. اگر کاربر فضای ابری عمومی هستید، لطفاً با پشتیبانی Apigee Edge تماس بگیرید.