502 Bad Gateway - DuplicateHeader

شما در حال مشاهده مستندات Apigee Edge هستید.
به مستندات Apigee X مراجعه کنید . اطلاعات

علامت

برنامه‌ی کلاینت، کد وضعیت HTTP 502 Bad Gateway را به همراه کد خطای protocol.http.DuplicateHeader به عنوان پاسخی برای فراخوانی‌های API دریافت می‌کند.

پیام خطا

برنامه‌ی کلاینت کد پاسخ زیر را دریافت می‌کند:

HTTP/1.1 502 Bad Gateway

علاوه بر این، ممکن است پیام خطایی مشابه آنچه در زیر نشان داده شده است را مشاهده کنید:

{
   "fault":{
      "faultstring":"Duplicate Header \"Expires\"",
      "detail":{
         "errorcode":"protocol.http.DuplicateHeader"
      }
   }
}

علل احتمالی

این خطا زمانی رخ می‌دهد که یک هدر HTTP خاص که در Apigee Edge مجاز به داشتن تکرار نیست، بیش از یک بار با مقادیر یکسان یا متفاوت، به عنوان بخشی از پاسخ HTTP ارسالی توسط سرور backend به Apigee Edge، ظاهر شود.

طبق RFC 7230، بخش 3.2.2: ترتیب فیلد ، فرستنده نباید چندین فیلد هدر با نام فیلد یکسان در یک پیام ایجاد کند، مگر اینکه یا کل مقدار فیلد برای آن فیلد هدر به عنوان یک لیست جدا شده با کاما تعریف شده باشد، [یعنی #(values)] یا فیلد هدر یک استثنای شناخته شده باشد. اگر Apigee Edge متوجه شود که یک هدر خاص یکسان، که مجاز به داشتن موارد تکراری نیست، بیش از یک بار در پاسخ HTTP ارسال شده توسط سرور هدف/backend ارسال شده است، با خطای 502 Bad Gateway و error code protocol.http.DuplicateHeader پاسخ می‌دهد.

در اینجا علل احتمالی این خطا آورده شده است:

علت توضیحات دستورالعمل‌های عیب‌یابی قابل اجرا برای
هدر تکراری در پاسخ پاسخ از سرور backend شامل هدرهای تکراری است. کاربران فضای ابری عمومی و خصوصی Edge

مراحل تشخیص مشترک

برای تشخیص این خطا از یکی از ابزارها/تکنیک‌های زیر استفاده کنید:

نظارت بر API

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

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

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

  3. به صفحه Analyze > API Monitoring > Investigate بروید.
  4. بازه زمانی خاصی را که در آن خطاها را مشاهده کرده‌اید، انتخاب کنید.
  5. مطمئن شوید که فیلتر پروکسی روی «همه» تنظیم شده است.
  6. رسم کد خطا در مقابل زمان .

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

    ( تصویر را بزرگتر ببینید )

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

    ( تصویر را بزرگتر ببینید )

  9. مطمئن شوید که کد وضعیت (Status Code) مطابق مثال بالا 502 باشد.
  10. روی «مشاهده گزارش‌ها» کلیک کنید و ردیف مربوط به درخواست ناموفق را باز کنید.

  11. از پنجره Logs، جزئیات زیر را یادداشت کنید:

    • کد وضعیت: 502
    • منبع خطا: target
    • کد خطا: protocol.http.DuplicateHeader .
  12. منبع خطا target است که نشان می‌دهد پاسخ از سرور backend حاوی هدرهای تکراری بوده است.

ابزار ردیابی

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

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

  2. مطمئن شوید که گزینه‌ی «نمایش تمام اطلاعات جریان» فعال است:

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

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

    ( تصویر را بزرگتر ببینید )

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

    ردیابی نمونه بالا خطایی با عنوان Duplicate Header "Expires" را نشان می‌دهد. از آنجایی که این خطا توسط Apigee پس از ارسال درخواست به سرور backend ایجاد شده است، نشان می‌دهد که سرور backend بیش از یک بار header Expires ارسال کرده است.

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

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

    ( تصویر را بزرگتر ببینید )

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

  10. بررسی کنید که آیا از زنجیره‌سازی پروکسی استفاده می‌کنید یا خیر؛ یعنی، آیا سرور یا نقطه پایانی هدف، پروکسی دیگری را در Apigee فراخوانی می‌کند یا خیر.

    1. برای تعیین این موضوع، به مرحله درخواست ارسال شده به سرور هدف برگردید. روی نمایش حلقه کلیک کنید.

    2. پنجره‌ی Curl for Request Sent to Target Server باز می‌شود که از طریق آن می‌توانید نام مستعار میزبان سرور هدف را تعیین کنید.

    3. اگر نام مستعار میزبان سرور هدف به یک نام مستعار میزبان مجازی اشاره کند، در این صورت از زنجیره‌سازی پروکسی استفاده می‌شود. در این حالت، باید تمام مراحل فوق را برای پروکسی زنجیره‌ای تکرار کنید تا زمانی که مشخص شود چه چیزی باعث خطای 502 Bad Gateway می‌شود.
    4. اگر نام مستعار میزبان سرور هدف به سرور backend شما اشاره کند، نشان می‌دهد که سرور backend شما هدرهای تکراری را در پاسخ به Apigee ارسال می‌کند.

انجینکس

برای تشخیص خطا با استفاده از گزارش‌های دسترسی NGINX:

  1. اگر شما یک کاربر Private Cloud هستید، می‌توانید از گزارش‌های دسترسی NGINX برای تعیین اطلاعات کلیدی در مورد خطاهای HTTP 502 استفاده کنید.

  2. گزارش‌های دسترسی NGINX را بررسی کنید:

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

    که در آن: ORG ، ENV و PORT# با مقادیر واقعی جایگزین شده‌اند.

  3. جستجو کنید تا ببینید آیا در یک بازه زمانی خاص خطای 502 وجود دارد یا خیر (اگر مشکل در گذشته رخ داده است) یا اینکه آیا درخواست‌هایی وجود دارد که هنوز با خطای 502 مواجه می‌شوند.

  4. اگر هرگونه خطای 502 با کد خطای X-Apigee-fault-code که با مقدار protocol.http.DuplicateHeader مطابقت دارد، پیدا کردید، مقدار منبع خطای X-Apigee-fault را تعیین کنید.

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

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

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

علت: هدر تکراری در پاسخ

تشخیص

  1. کد خطا و منبع خطا را برای خطای مشاهده شده با استفاده از API Monitoring یا گزارش‌های دسترسی NGINX، همانطور که در مراحل تشخیص مشترک توضیح داده شده است، تعیین کنید.
  2. اگر منبع خطا مقدار target داشته باشد، نشان می‌دهد که پاسخ ارسالی توسط سرور هدف حاوی هدرهای تکراری است.

  3. شما می‌توانید با استفاده از یکی از روش‌های زیر، هدر واقعی که بیش از یک بار به عنوان بخشی از پاسخ ارسال می‌شود را تعیین کنید:

    پیام خطا

    استفاده از پیام خطا:

    1. اگر به پیام خطای کامل دریافتی از Apigee Edge دسترسی دارید، به faultstring مراجعه کنید. faultstring شامل نام هدری است که بیش از یک بار ارسال شده است.

      نمونه پیام خطا:

      "faultstring":"Duplicate Header \"Expires\""
    2. در پیام خطای بالا، همانطور که در faultstring مشاهده می‌شود، می‌توانید ببینید که هدر Expires بیش از یک بار ارسال شده است.

    درخواست واقعی

    استفاده از درخواست واقعی:

    1. اگر به درخواست واقعی ارسال شده به سرور هدف دسترسی ندارید، دستور curl مربوطه را از بخش «استفاده از ابزار Trace» در مراحل 10.a و 10.b دریافت کنید.

    2. اگر به درخواست واقعی ارسال شده به برنامه سرور هدف دسترسی دارید، مراحل زیر را انجام دهید:

      1. با سرور هدف تماس بگیرید.

        نمونه درخواست برای سرور هدف مورد استفاده در این مثال:

        curl -X GET "https://BACKEND_SERVER_HOST/response-headers?Expires=Mon%2C%2021%20June%202021%2007%3A28%3A00%20GMT&Expires=Mon%2C%2021%20June%202021%2007%3A28%3A00%20GMT" -v

      2. لیست هدرهای مشاهده شده در پاسخ را تأیید کنید.

        نمونه پاسخ از سرور هدف مورد استفاده در این مثال:

        * ...Trimmed...
> GET /response-headers?Expires=Mon%2C%2021%20June%202021%2007%3A28%3A00%20GMT&Expires=Mon%2C%2021%20June%202021%2007%3A28%3A00%20GMT HTTP/2
> Host: BACKEND_SERVER_HOST
> User-Agent: curl/7.64.1
> Accept: */*
>
* Connection state changed (MAX_CONCURRENT_STREAMS == 128)!
< HTTP/2 200
< date: Fri, 02 Jul 2021 05:29:07 GMT
< content-type: application/json
< content-length: 166
< server: gunicorn/19.9.0
< Expires: Mon, 21 June 2021 07:28:00 GMT
< Expires: Mon, 21 June 2021 07:28:00 GMT
< access-control-allow-origin: *
< access-control-allow-credentials: true
<
----<Response BODY>------
* Connection #0 to host httpbin.org left intact
* Closing connection 0

        در درخواست مثال بالا، هدر Expires بیش از یک بار ارسال می‌شود. بنابراین، این درخواست با خطای 502 Bad Gateway و کد خطا: protocol.http.DuplicateHeader با شکست مواجه می‌شود.

      3. اگر هدری که نام آن در faultstring آمده است، بیش از یک بار در پاسخ سرور backend ظاهر شود، دلیل این خطا همین است. در مورد فوق، هدر Expires بیش از یک بار ارسال شده است.

وضوح تصویر

رفع مشکل تکراری بودن

گزینه شماره ۱ [گزینه پیشنهادی] سرور بک‌اند را طوری تنظیم کنید که هدرهای تکراری را شامل نشود

  1. دلیل ارسال تکراری بودن هدر Expires توسط سرور بک‌اند خاص را تجزیه و تحلیل کنید و بررسی کنید که آیا پذیرش آن توسط پراکسی‌های API اشکالی ندارد یا خیر. در بیشتر موارد، طبق مشخصات HTTP RFC7230 ، این کار مطلوب نخواهد بود.
  2. اگر مطلوب نیست، برنامه سرور هدف خود را طوری تغییر دهید که هدرهای تکراری ارسال نکند. در مثالی که در بالا مورد بحث قرار گرفت، مشاهده می‌شود که هدر Expires دو بار با مقدار یکسان ارسال می‌شود که مطلوب نیست. می‌توانید با اطمینان از اینکه سرور هدف فقط یک بار هدر Expires را ارسال می‌کند، این مشکل را برطرف کنید.
  3. اگر مطلوب است و می‌خواهید هدرهای تکراری را مجاز کنید، به گزینه شماره ۲ با استفاده از ویژگی CwC بروید.

سی دبلیو سی

گزینه شماره ۲ استفاده از ویژگی CwC

Apigee یک ویژگی CwC HTTPHeader.<HeaderName> ارائه می‌دهد که به برنامه‌های کلاینت و سرورهای هدف اجازه می‌دهد تا هدرهای تکراری را به پروکسی‌های API در Apigee Edge ارسال کنند.

ملک CwC ارزش‌ها
HTTPHeader.<HeaderName> allowDuplicates,multivalued

برای مثال، می‌توان ویژگی زیر را روی پردازنده‌های پیام تنظیم کرد تا مقادیر تکراری و چندگانه برای هدر Expires مجاز باشند.

HTTPHeader.Expires=allowDuplicates, multiValued
  1. اگر شما یک کاربر Private Cloud هستید، می‌توانید با استفاده از راهنمای نحوه‌ی پیکربندی پردازنده‌های پیام برای استفاده از هدرهای تکراری ، این ویژگی را طوری پیکربندی کنید که از ایجاد خطای 502 Bad Gateway در Apigee Edge جلوگیری کند، حتی اگر درخواست حاوی هدرهای تکراری باشد.
  2. اگر شما یک کاربر فضای ابری عمومی هستید، برای پیکربندی این ویژگی برای سازمان خود با پشتیبانی Apigee Edge تماس بگیرید.

مشخصات

Apigee با خطای 502 Bad Gateway پاسخ می‌دهد، زیرا انتظار دارد سرور backend مطابق با مشخصات RFC زیر رفتار کند:

مشخصات
RFC 7230، بخش 3.2.2: ترتیب فیلد
RFC 7230، بخش 3.2: فیلدهای سرآیند

اگر هنوز به هرگونه کمکی از پشتیبانی Apigee نیاز دارید، به بخش «باید اطلاعات تشخیصی را جمع‌آوری کنید» بروید.

باید اطلاعات تشخیصی جمع‌آوری کند

اطلاعات تشخیصی زیر را جمع‌آوری کنید و سپس با پشتیبانی Apigee Edge تماس بگیرید.

اگر کاربر فضای ابری عمومی هستید، اطلاعات زیر را ارائه دهید:

  • نام سازمان
  • نام محیط
  • نام پروکسی API
  • دستور curl کامل که برای بازتولید خطای 502 استفاده می‌شود
  • فایل ردیابی برای درخواست‌های API

اگر کاربر Private Cloud هستید، اطلاعات زیر را ارائه دهید:

  • پیام خطای کامل مشاهده شده برای درخواست‌های ناموفق
  • نام محیط
  • بسته پروکسی API
  • فایل ردیابی برای درخواست‌های 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