400 درخواست بد - DuplicateHeader

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

علامت

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

پیغام خطا

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

HTTP/1.1 400 Bad Request

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

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

علل احتمالی

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

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

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

علت توضیحات دستورالعمل های عیب یابی قابل اجرا برای
هدر تکراری در درخواست درخواست HTTP از برنامه مشتری به Apigee حاوی هدرهای تکراری است. کاربران 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. روی View logs کلیک کنید و ردیف درخواست ناموفق را گسترش دهید.
  10. از پنجره Logs به جزئیات زیر توجه کنید:
    1. کد وضعیت: 400
    2. منبع خطا: apigee
    3. کد خطا: protocol.http.DuplicateHeader .
  11. اگر منبع خطا دارای مقدار apigee یا MP باشد MP و کد خطا دارای protocol.http.DuplicateHeader مقدار است.http.DuplicateHeader است، سپس این نشان می دهد که درخواست HTTP از مشتری حاوی هدرهای تکراری است.

ابزار ردیابی

NGINX

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

  1. اگر کاربر Private Cloud هستید، می توانید از گزارش های دسترسی 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 مطابق با مقدار protocol.http.DuplicateHeader پیدا کردید، سپس مقدار X-Apigee-fault-source را تعیین کنید.

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

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

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

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

تشخیص

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

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

    پیغام خطا

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

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

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

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

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

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

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

      1. لیست سرصفحه های ارسال شده در درخواست را تأیید کنید.
      2. اگر متوجه شدید که یک هدر خاص بیش از یک بار در درخواست با مقدار یکسان یا مقادیر متفاوت ظاهر می شود، دلیل این خطا همین است.

      نمونه درخواست:

      curl https://HOST_ALIAS/duplicateheadertest -v -H "Expires: Mon, 21 June 2021 07:28:00 GMT" -H "Expires: Mon, 21 June 2021 07:28:00 GMT"

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

    2. از طرف دیگر، اگر به گزارش‌های مشتری دسترسی دارید، می‌توانید ببینید که آیا اطلاعاتی در مورد درخواست واقعی ارائه شده به Apigee Edge دارید یا خیر و هدری را که بیش از یک بار ارسال می‌شود تعیین کنید.

قطعنامه

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

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

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

    در مثالی که در بالا مورد بحث قرار گرفت، مشاهده شد که هدر Expires دو بار با همان مقدار ارسال می شود که مطلوب نیست. همانطور که در زیر نشان داده شده است، می توانید مشکل را با عبور از سربرگ Expires فقط یک بار برطرف کنید:

    curl https://HOST_ALIAS/duplicateheadertest -v -H "Expires: Mon, 21 June 2021 07:28:00 GMT"
  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 از ایجاد خطای 400 Bad Request جلوگیری کند، حتی اگر درخواست حاوی سرصفحه‌های تکراری با استفاده از پیکربندی پردازشگرهای پیام برای استفاده از راهنمای نحوه استفاده از هدرهای تکراری باشد .
  2. اگر کاربر Public Cloud هستید، با پشتیبانی Apigee Edge تماس بگیرید تا این ویژگی را برای سازمان خود پیکربندی کنید.

مشخصات

Apigee از برنامه مشتری انتظار دارد که هدرهای تکراری را به عنوان بخشی از درخواست مطابق با مشخصات RFC زیر ارسال نکند:

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

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

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

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

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

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

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

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