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

شما در حال مشاهده مستندات 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 و error code protocol.http.DuplicateHeader پاسخ می‌دهد.

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

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

ابزار ردیابی

انجینکس

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

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

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

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

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

تشخیص

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

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

    پیام خطا

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

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

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

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

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

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

    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

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

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

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

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

مشخصات

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

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

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

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

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

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

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