‫۴۰۰ درخواست نادرست - سرصفحه تکراری

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

نشانه

برنامه مشتری کد وضعیت HTTP 400 Bad Request را با کد خطای protocol.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: ترتیب فیلد، فرستنده نباید چندین فیلد سرایند با نام فیلد یکسان در پیام تولید کند، مگر اینکه کل مقدار فیلد برای آن فیلد سرایند به‌عنوان فهرست جداشده با کاما تعریف شده باشد، [یعنی ‫#(values)] یا فیلد سرایند یک استثنای شناخته‌شده است. اگر Apigee Edge سرایند خاصی را پیدا کند که اجازه ندارد بیش‌از یک بار در درخواست HTTP ارسال‌شده توسط مشتری تکرار شود، با 400 Bad Request و کد خطای protocol.http.DuplicateHeader پاسخ می‌دهد.

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

علت شرح دستورالعمل‌های عیب‌یابی برای موارد زیر قابل‌اجرا است
سرایند تکراری در درخواست درخواست HTTP از برنامه مشتری به Apigee حاوی سرصفحه‌های تکراری است. کاربران «فضای ابری خصوصی و عمومی لبه‌ای»

مراحل متداول تشخیص خرابی

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

پایش میانای برنامه‌سازی کاربردی

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

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

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

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

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

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

  9. روی مشاهده گزارش‌ها کلیک کنید و ردیف درخواست ناموفق را ازهم باز کنید.
  10. از پنجره گزارش‌ها، جزئیات زیر را یادداشت کنید:
    1. کد وضعیت: 400
    2. منبع خطا: apigee
    3. کد خطا: protocol.http.DuplicateHeader.
  11. اگر منبع خطا مقدار apigee یا MP را داشته باشد و کد خطا مقدار protocol.http.DuplicateHeader را داشته باشد، این نشان می‌دهد که درخواست HTTP از کاربر حاوی سرایندهای تکراری بوده است.

ابزار ردیابی

NGINX

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

  1. اگر کاربر «ابر خصوصی» هستید، می‌توانید از گزارش‌های دسترسی NGINX برای تعیین اطلاعات کلیدی درباره خطاهای 400 HTTP استفاده کنید.

  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 را تعیین کنید.

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

    ورودی نمونه بالا از گزارش NGINX Access مقادیر زیر را برای 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. دلیل ارسال سرصفحه تکراری توسط مشتری خاص را تجزیه‌وتحلیل کنید. برای مثال، Expires در مورد بالا. تأیید کنید که پراکسی‌های API می‌توانند سرصفحه تکراری را بپذیرند. معمولاً طبق مشخصات HTTP RFC7230 مطلوب نیست.
  2. اگر مطلوب نیست، برنامه کارخواهتان را اصلاح کنید تا سربرگ‌های تکراری ارسال نکند.

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

    curl https://HOST_ALIAS/duplicateheadertest -v -H "Expires: Mon, 21 June 2021 07:28:00 GMT"
  3. اگر مطلوب است و می‌خواهید سرصفحه‌های تکراری را مجاز کنید، به گزینه شماره ۲ بااستفاده از دارایی CwC بروید.

CwC

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

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

دارایی CwC مقادیر
HTTPHeader.<HeaderName> allowDuplicates,multivalued

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

HTTPHeader.Expires=allowDuplicates, multiValued
  1. اگر کاربر «ابر خصوصی» هستید، می‌توانید دارایی را پیکربندی کنید تا از ایجاد خطای 400 Bad Request توسط Apigee Edge جلوگیری کنید، حتی اگر درخواست شامل سربرگ‌های تکراری باشد، بااستفاده از راهنمای گام‌به‌گام پیکربندی «پردازشگرهای پیام» برای استفاده از سربرگ‌های تکراری.
  2. اگر کاربر «ابر عمومی» هستید، برای پیکربندی این دارایی برای سازمانتان با پشتیبانی Apigee Edge تماس بگیرید.

مشخصات

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

مشخصات
‫RFC 7230، بخش ۳.۲.۲: ترتیب فیلد
‫RFC 7230، بخش ۳.۲ فیلدهای سرایند

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

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

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

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

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