415 نوع رسانه پشتیبانی نشده - رمزگذاری پشتیبانی نشده

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

علامت

برنامه سرویس گیرنده یک کد وضعیت HTTP 415 Unsupported Media Type با protocol.http.UnsupportedEncoding کد خطا دریافت می کند.http.UnsupportedEncoding به عنوان پاسخ به تماس های API.

پیغام خطا

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

HTTP/1.1 415 Unsupported Media Type

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

{
   "fault":{
      "faultstring":"Unsupported Encoding \"UTF-8\"",
      "detail":{
         "errorcode":"protocol.http.UnsupportedEncoding"
      }
   }
}

علل احتمالی

این خطا در صورتی رخ می‌دهد که مقدار هدر Content-Encoding که در درخواست HTTP ارسال شده توسط مشتری به Apigee یا پاسخ HTTP ارسال شده توسط سرور backend به Apigee مشخص شده است، مطابق با مشخصات RFC 7231 حاوی کدگذاری پشتیبانی‌شده توسط Apigee نباشد. ، بخش 6.5.13: 415 نوع رسانه پشتیبانی نشده .

دلایل احتمالی این خطا به شرح زیر است:

علت توضیحات دستورالعمل های عیب یابی قابل اجرا برای
رمزگذاری پشتیبانی نشده مورد استفاده در درخواست هدر درخواست Content-Encoding حاوی رمزگذاری است که توسط Apigee Edge پشتیبانی نمی‌شود. کاربران Edge Public و Private Cloud
در پاسخ از رمزگذاری پشتیبانی نشده استفاده شده است هدر پاسخ سرور باطن Content-Encoding حاوی رمزگذاری است که توسط Apigee Edge پشتیبانی نمی‌شود. کاربران Edge Public و Private Cloud

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

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

مانیتورینگ API

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

  1. به حساب Apigee Edge خود وارد شوید .

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

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

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

    سلول کد خطا انتخاب شده است

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

  9. برای مشاهده اطلاعات بیشتر، روی View logs کلیک کنید و یکی از درخواست‌های شکست خورده با خطای 415 را گسترش دهید:

  10. از پنجره Logs به جزئیات زیر توجه کنید:
    • منبع خطا: این نشان می دهد که خطا توسط apigee یا target برگردانده شده است.
    • کد خطا: باید با protocol.http.UnsupportedEncoding مطابقت داشته باشد.
  11. اگر منبع خطا apigee باشد، این نشان می‌دهد که درخواست حاوی کدگذاری پشتیبانی‌نشده در سربرگ Content-Encoding است.
  12. اگر منبع خطا target باشد، این نشان می‌دهد که پاسخ سرور پشتیبان حاوی کدگذاری پشتیبانی‌نشده در سربرگ Content-Encoding است.

ابزار ردیابی

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

  1. جلسه ردیابی را فعال کنید و یا:
    • منتظر بمانید تا خطای 415 Unsupported Media Type رخ دهد یا
    • اگر می‌توانید مشکل را بازتولید کنید، برای بازتولید خطای 415 Unsupported Media Type با API تماس بگیرید.

  2. مطمئن شوید که Show all FlowInfos فعال باشد:

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

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

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

    ردیابی نمونه بالا خطا را به عنوان Unsupported Encoding "utf-8" نشان می دهد. از آنجایی که این خطا توسط Apigee پس از ارسال درخواست به سرور باطن مطرح می‌شود، نشان می‌دهد که سرور بک‌اند سرصفحه پاسخ Content-Encoding را با مقدار "utf-8" ارسال کرده است، که یک کدگذاری پشتیبانی‌شده در Apigee نیست.

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

  8. به قسمت Error / Response Headers در پانل جزئیات فاز بروید و مقادیر X-Apigee-fault-code و X-Apigee-fault-source را مطابق شکل زیر تعیین کنید:

  9. مقادیر X-Apigee-fault-code و X-Apigee-fault-source را "utf-8" عنوان protocol.http.UnsupportedEncoding مشاهده خواهید کرد target سرور باطن در هدر پاسخ Content-Encoding .

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

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

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

    2. پنجره Curl for Request Sent to Target Server باز می شود که از آن می توانید نام مستعار میزبان سرور مورد نظر را تعیین کنید.
    3. اگر نام مستعار میزبان سرور هدف به یک نام مستعار میزبان مجازی اشاره می کند، آنگاه زنجیره پروکسی است. در این حالت، باید تمام مراحل بالا را برای پراکسی زنجیره‌ای تکرار کنید تا مشخص کنید که چه چیزی باعث خطای 415 Unsupported Media Type است.
    4. اگر نام مستعار میزبان سرور مورد نظر به سرور باطن شما اشاره کند، این نشان می دهد که سرور باطن شما رمزگذاری پشتیبانی نشده را به Apigee ارسال می کند.

گزارش های دسترسی Nginix

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

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

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

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

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

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

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

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

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

    X-Apigee-fault-source نیز می تواند این را داشته باشد target ارزش .

علت: رمزگذاری پشتیبانی نشده در درخواست

تشخیص

  1. کد خطا و منبع خطا را برای خطای مشاهده شده با استفاده از مانیتورینگ API یا گزارش های دسترسی NGINX همانطور که در مراحل تشخیص رایج توضیح داده شده است، تعیین کنید.
  2. اگر کد خطا protocol.http.UnsupportedEncoding باشد و منبع خطا دارای مقدار apigee یا MP باشد، این نشان می‌دهد که درخواست ارسال شده توسط برنامه مشتری حاوی رمزگذاری پشتیبانی‌نشده در سرصفحه درخواست Content-Encoding است.
  3. با استفاده از یکی از روش‌های زیر می‌توانید مقدار کدگذاری پشتیبانی‌نشده را که به عنوان بخشی از درخواست HTTP ارسال شده است، تعیین کنید:

    پیغام خطا

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

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

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

      "faultstring":"Unsupported Encoding \"UTF-8\""

    2. در پیام خطای بالا، توجه کنید که مقدار رمزگذاری پشتیبانی‌نشده “UTF-8” است، همانطور که در faultstring مشاهده می‌شود.

      از آنجایی که “UTF-8” یک کدگذاری پشتیبانی شده در Apigee Edge نیست، این درخواست با خطای 415 Unsupported Media Type با کد خطا: protocol.http.UnsupportedEncoding انجام نمی‌شود.

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

    با استفاده از درخواست واقعی:
    1. اگر به درخواست واقعی ارائه شده توسط برنامه مشتری دسترسی ندارید، به Resolution بروید.
    2. اگر به درخواست واقعی ارائه شده توسط برنامه مشتری دسترسی دارید، مراحل زیر را انجام دهید:
      1. مقدار ارسال شده به هدر درخواست Content-Encoding.
      2. اگر مقدار ارسال شده به سرصفحه درخواست Content-Encoding یکی از مقادیر فهرست شده در رمزگذاری پشتیبانی شده نباشد، دلیل این خطا همین است.

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

        curl -v "https://HOSTALIAS/v1/testgzip" -H "Content-Encoding: UTF-8" -X POST -d @request_payload.gz

        درخواست نمونه بالا مقدار "UTF-8" به سربرگ Content- Encoding ارسال می کند که یک کدگذاری پشتیبانی شده در Apigee Edge نیست. بنابراین، این درخواست با خطای 415 Unsupported Media Type با کد خطا: protocol.http.UnsupportedEncoding انجام نمی‌شود.

قطعنامه

  1. به لیست رمزگذاری های پشتیبانی شده توسط Apigee در رمزگذاری پشتیبانی شده مراجعه کنید.
  2. اطمینان حاصل کنید که برنامه مشتری همیشه موارد زیر را ارسال می کند:
    • فقط رمزگذاری پشتیبانی شده به عنوان مقدار هدر Content-Encoding در درخواست
    • بار درخواست در قالب پشتیبانی شده به Apigee Edge و با قالب مشخص شده در هدر Content-Encoding مطابقت دارد

  3. در مثال بالا، پیلود درخواست دارای پسوند gz است که نشان می‌دهد محتوا باید gzip باشد. می‌توانید با ارسال سرصفحه درخواست به‌عنوان Content-Encoding: gzip و بار درخواست در قالب gzip مشکل را برطرف کنید:

    curl -v "https://HOSTALIAS/v1/testgzip" -H "Content-Encoding: gzip" -X POST -d @request_payload.gz

علت: رمزگذاری پشتیبانی نشده در پاسخ

تشخیص

  1. کد خطا و منبع خطا را برای خطای مشاهده شده با استفاده از API Monitoring، Trace Tool یا گزارش های دسترسی NGINX همانطور که در مراحل تشخیص رایج توضیح داده شده است، تعیین کنید.
  2. اگر منبع خطا دارای مقدار target باشد، این نشان می دهد که پاسخ ارسال شده توسط سرور باطن حاوی کدگذاری پشتیبانی نشده در سربرگ Content-Encoding است.
  3. با استفاده از یکی از روش‌های زیر می‌توانید مقدار کدگذاری پشتیبانی‌نشده را که به عنوان بخشی از پاسخ HTTP از سرور باطن ارسال می‌شود، تعیین کنید:

    پیغام خطا

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

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

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

      "faultstring":"Unsupported Encoding \"UTF-8\""

    2. در پیام خطای بالا، توجه کنید که مقدار رمزگذاری پشتیبانی‌نشده “UTF-8” است، همانطور که در faultstring مشاهده می‌شود.

      از آنجایی که “UTF-8” یک کدگذاری پشتیبانی شده در Apigee Edge نیست، این درخواست با خطای 415 Unsupported Media Type با کد خطا: protocol.http.UnsupportedEncoding انجام نمی‌شود.

    ابزار ردیابی

    استفاده از Trace:
    1. اگر ردیابی درخواست ناموفق را ندارید، به Resolution بروید.
    2. اگر ردی برای شکست ثبت کرده‌اید، می‌توانید رمزگذاری پشتیبانی‌نشده‌ای را که توسط سرور باطن ارسال شده به عنوان بخشی از سرصفحه پاسخ Content-Encoding همانطور که در ابزار Trace توضیح داده شده است، تعیین کنید.

قطعنامه

  1. به لیست رمزگذاری های پشتیبانی شده توسط Apigee در رمزگذاری پشتیبانی شده مراجعه کنید
  2. اطمینان حاصل کنید که سرور باطن همیشه موارد زیر را ارسال می کند:
    • فقط رمزگذاری پشتیبانی شده به عنوان مقدار هدر Content-Encoding در درخواست
    • بار پاسخ در قالب پشتیبانی شده به Apigee Edge و با قالب مشخص شده در سربرگ Content-Encoding مطابقت دارد.

پشتیبانی از رمزگذاری

جدول زیر فرمت کدگذاری پشتیبانی شده توسط Apigee Edge را فهرست می کند:

سربرگ رمزگذاری توضیحات
Content-Encoding gzip فرمت یونیکس gzip
deflate این فرمت از ساختار zlib با الگوریتم فشرده سازی deflate استفاده می کند.

مشخصات

Apigee با پاسخ خطای 415 Unsupported Media Type مطابق مشخصات RFC زیر پاسخ می‌دهد:

مشخصات
RFC 7231، بخش 6.5.13: 415 نوع رسانه پشتیبانی نشده

نکات کلیدی قابل توجه

به موارد زیر توجه کنید:

  • اگر خطای 415 توسط Apigee به دلیل رمزگذاری پشتیبانی نشده که در سربرگ Content-Encoding به عنوان بخشی از درخواست API ارسال شده است، برگردانده شود، پس:
    • شما نمی توانید برای چنین درخواست هایی ردیابی کنید.

    • شما نمی توانید قالب یا محتوای پاسخ خطای ارسال شده توسط Apigee Edge را با استفاده از سیاست هایی مانند RaiseFault، AssignMessage تغییر دهید.

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

  • اگر خطای 415 توسط Apigee به دلیل رمزگذاری پشتیبانی نشده ارسال شده در هدر پاسخ از سرور باطن شما برگردانده شود، برای جلوگیری از این خطا باید در سرور باطن رفع شود . لطفاً برای رفع این مشکل با تیم پشتیبان خود در حد مناسب کار کنید.

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

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

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

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

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