502 Bad Gateway - DuplicateHeader

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

علامت

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

پیغام خطا

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

HTTP/1.1 502 Bad Gateway

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

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

علل احتمالی

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

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

در اینجا دلایل احتمالی این خطا وجود دارد:

علت توضیحات دستورالعمل های عیب یابی قابل اجرا برای
هدر تکراری در پاسخ پاسخ سرور پشتیبان حاوی هدرهای تکراری است. کاربران Edge Public و Private Cloud

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

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

مانیتورینگ API

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

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

  2. به سازمانی که می‌خواهید در آن موضوع را بررسی کنید بروید.

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

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

    ( مشاهده تصویر بزرگتر )

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

    ( مشاهده تصویر بزرگتر )

  9. همانطور که در مثال بالا نشان داده شده است، اطمینان حاصل کنید که کد وضعیت 502 است.
  10. روی View logs کلیک کنید و ردیف درخواست ناموفق را گسترش دهید.

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

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

ابزار ردیابی

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

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

  2. اطمینان حاصل کنید که نمایش همه اطلاعات جریان فعال است:

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

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

    ( مشاهده تصویر بزرگتر )

  6. به مقدار خطا از ردیابی توجه کنید.

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

  7. در Trace به فاز AX (Analytics Data Recorded) بروید و روی آن کلیک کنید.

  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 مشاهده خواهید کرد.http.DuplicateHeader و target ، که نشان می دهد این خطا به دلیل ارسال هدرهای تکراری توسط سرور backend برای سرصفحه پاسخ Expires شده است. .
    سرصفحه های پاسخ ارزش
    X-Apigee-fault-code protocol.http.DuplicateHeader
    X-Apigee-fault-source target

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

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

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

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

NGINX

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

    نمونه خطای 502 از گزارش دسترسی NGINX:

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

    سرصفحه های پاسخ ارزش
    X-Apigee-fault-code protocol.http.DuplicateHeader
    X-Apigee-fault-source target

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

تشخیص

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

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

    پیغام خطا

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

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

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

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

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

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

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

    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 نشان داده می شود بیش از یک بار در پاسخ سرور باطن ظاهر می شود، این دلیل این خطا است. در حالت فوق، هدر Expires بیش از یک بار ارسال می شود.

قطعنامه

رفع کپی برداری

گزینه شماره 1 [گزینه پیشنهادی] سرور باطن را طوری اصلاح کنید که سرصفحه های تکراری را شامل نشود

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

CwC

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

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

دارایی CwC ارزش ها
HTTPHeader.<HeaderName> allowDuplicates,multivalued

به عنوان مثال، ویژگی زیر را می‌توان روی Message Processors تنظیم کرد تا مقادیر تکراری و چندگانه برای سرصفحه Expires مجاز باشد.

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

مشخصات

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

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

اگر همچنان به کمک پشتیبانی Apigee نیاز دارید، به Must collect information diagnostic بروید.

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

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

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

  • نام سازمان
  • نام محیط زیست
  • نام پروکسی 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