400 Bad Request - DecompressionFailureAtRequest

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

علامت

برنامه مشتری کد وضعیت HTTP 400 Bad Request با کد خطا messaging.adaptors.http.flow.DecompressionFailureAtRequest را به عنوان پاسخی به تماس های API دریافت می کند.

پیغام خطا

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

HTTP/1.1 400 Bad Request

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

{
   "fault":{
      "faultstring":"Decompression failure at request",
      "detail":{
         "errorcode":"messaging.adaptors.http.flow.DecompressionFailureAtRequest"
      }
   }
}

علل احتمالی

این خطا فقط در صورتی رخ می دهد که:

• رمزگذاری مشخص شده در هدر درخواست HTTP Content-Encoding معتبر است و توسط Apigee Edge پشتیبانی می‌شود .

اما

• فرمت بار ارسال شده توسط مشتری به عنوان بخشی از درخواست HTTP با قالب کدگذاری مشخص شده در سربرگ Content-Encoding مطابقت ندارد.

این به این دلیل است که Apigee Edge نمی‌تواند محموله را با استفاده از رمزگذاری مشخص شده رمزگشایی کند زیرا قالب بار با فرمت کدگذاری مشخص شده در سربرگ Content-Encoding نیست.

در اینجا چند نمونه از مقادیر پشتیبانی شده Content-Encoding و نحوه انتظار Apigee Edge از فرمت بارگذاری در این موارد وجود دارد:

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

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

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

علت: فرمت بار درخواستی با رمزگذاری مشخص شده در سرصفحه Content-Encoding مطابقت ندارد

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

تشخیص

1. کد خطا و منبع خطا را برای خطای مشاهده شده با استفاده از مانیتورینگ API، ابزار Trace یا گزارش های دسترسی NGINX همانطور که در مراحل تشخیص رایج توضیح داده شده است، تعیین کنید.
2. اگر کد خطا messaging.adaptors.http.flow.DecompressionFailureAtRequest باشد و منبع خطا دارای policy مقدار یا proxy باشد، این نشان می دهد که درخواست ارسال شده توسط برنامه مشتری دارای باری است که با رمزگذاری پشتیبانی شده مشخص شده در هدر درخواست مطابقت ندارد. Content-Encoding .

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

   پیغام خطا

   برای تأیید اعتبار با استفاده از پیام خطا:

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

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

      "faultstring":"Decompression failure at request"

   2. در پیغام خطای بالا، "Decompression failure at request" نمایش داده می شود که به این معنی است که درخواست را نمی توان با استفاده از رمزگذاری مشخص شده در هدر Content-Encoding از حالت فشرده خارج کرد.

   ردیابی

   برای تأیید اعتبار با استفاده از Trace:

   1. مقدار هدر درخواست Content-Encoding و ویژگی error.cause را با استفاده از Trace همانطور که در مراحل تشخیص رایج توضیح داده شده است، تعیین کنید.

   2. مقادیر ردیابی نمونه به شرح زیر است:

      • رمزگذاری محتوا: gzip
      • error.cause: Not in GZIP format

      مقدار در هدر درخواست Content-Encoding gzip است. با این حال، بارگیری درخواستی در قالب GZIP نیست (همانطور که با error.cause نشان داده شده است). بنابراین، Apigee Edge با 400 Bad Request و کد خطا messaging.adaptors.http.flow.DecompressionFailureAtRequest پاسخ می دهد.

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

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

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

   1. مقدار ارسال شده به هدر درخواست Content-Encoding را تعیین کنید.
   2. فرمت بار ارسال شده به عنوان بخشی از درخواست را تعیین کنید.

   3. اگر مقدار هدر Content-Encoding در لیست رمزگذاری های پشتیبانی شده باشد اما قالب بار درخواست با رمزگذاری مشخص شده در هدر Content-Encoding مطابقت ندارد، دلیل این مشکل همین است.

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

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

      درخواست نمونه بالا مقدار gzip به سربرگ Content-Encoding ارسال می کند که یک کدگذاری پشتیبانی شده در Apigee Edge است. با این حال، درخواست payload request_payload.zip در قالب ZIP است. بنابراین، این درخواست با کد وضعیت 400 Bad Request و کد خطا: messaging.adaptors.http.flow.DecompressionFailureAtRequest با شکست مواجه می شود.

   گزارش‌های پردازشگر پیام

   برای تأیید اعتبار با استفاده از گزارش‌های پردازشگر پیام:

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

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

   2. شناسه پیام را در گزارش پردازشگر پیام جستجو کنید:

      /opt/apigee/var/log/edge-message-processor/logs/system.log

   3. یکی از استثناهای زیر را خواهید دید:

      سناریوی شماره 1

      سناریوی شماره 1: وقتی درخواست API دارای سرصفحه Content-Encoding: gzip باشد

      2021-07-28 10:21:16,861  NIOThread@0 ERROR HTTP.SERVER -
      HTTPServer$Context.onInputException() : Message id:rt-57-1
      SSLClientChannel[Accepted: Remote:192.168.199.8:8443
      Local:192.168.80.234:44284]@28469 useCount=1 bytesRead=0
      bytesWritten=28764 age=2739893ms  lastIO=0ms
      isOpen=true.onExceptionRead exception: {}
      java.util.zip.ZipException: Not in GZIP format
      
      2021-07-28 10:21:16,862  NIOThread@0 ERROR ADAPTORS.HTTP.FLOW -
      AbstractRequestListener.onException() : Request:POST, uri:/test,
      message Id:rt-57-1, exception:java.util.zip.ZipException: Not in GZIP format,
      context:Context@71ea5ac input=ClientInputChannel(SSLClientChannel[Accepted:
      Remote:192.168.199.8:8443 Local:192.168.80.234:44284]@28469 useCount=1
      bytesRead=0 bytesWritten=28764 age=2739894ms  lastIO=0ms  isOpen=true)
      2021-07-28 10:21:16,862  NIOThread@0 INFO  HTTP.SERVICE -
      ExceptionHandler.handleException() :
      Exception java.util.zip.ZipException: Not in GZIP format occurred while writing
      to channel null
      2021-07-28 10:21:16,863  NIOThread@0 INFO  HTTP.SERVICE -
      ExceptionHandler.handleException() : Exception trace:
      java.util.zip.ZipException: Not in GZIP format
      

      خط java.util.zip.ZipException: Not in GZIP format در پیام خطای بالا نشان می دهد که بار درخواست در قالب GZIP ارسال نشده است اگرچه Content-Encoding به عنوان gzip مشخص شده است. بنابراین، Apigee Edge استثنا را ایجاد می‌کند و یک کد وضعیت 400 با کد خطا messaging.adaptors.http.flow.DecompressionFailureAtRequest را به برنامه‌های کلاینت برمی‌گرداند.

      سناریوی شماره 2

      سناریوی شماره 2: وقتی درخواست API دارای سرصفحه Content-Encoding: deflate باشد

      2021-07-28 15:26:31,893  NIOThread@1 ERROR HTTP.SERVER -
      HTTPServer$Context.onInputException() : Message id:rt-47875-1
      SSLClientChannel[Accepted: Remote:192.168.199.8:8443
      Local:192.168.81.72:45954]@29276 useCount=1 bytesRead=0
      bytesWritten=37230 age=3498856ms  lastIO=1ms
      isOpen=true.onExceptionRead exception: {}
      java.util.zip.ZipException: incorrect header check
                        ….
      Caused by: java.util.zip.DataFormatException: incorrect header check
             ..
      2021-07-28 15:26:31,894  NIOThread@1 ERROR ADAPTORS.HTTP.FLOW -
      AbstractRequestListener.onException() : Request:POST, uri:/test,
      message Id:rrt-47875-1, exception:java.util.zip.ZipException:
      incorrect header check, context:Context@69b3ac45
      input=ClientInputChannel(SSLClientChannel[Accepted:
      Remote:192.168.199.8:8443 Local:192.168.81.72:45954]@29276
      useCount=1 byt	esRead=0 bytesWritten=37230 age=3498856ms
      lastIO=1ms  isOpen=true)
      

      خطوط java.util.zip.ZipException: incorrect header check و Caused by: java.util.zip.DataFormatException: incorrect header check در پیام خطای بالا نشان می دهد که بار درخواست در قالب deflate ارسال نشده و با کدگذاری مطابقت ندارد در هدر Content-Encoding از deflate مشخص شده است. بنابراین، Apigee Edge استثنا را ایجاد می‌کند و یک کد وضعیت 400 با کد خطا messaging.adaptors.http.flow.DecompressionFailureAtRequest را به برنامه‌های کلاینت برمی‌گرداند.

قطعنامه

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

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

مشخصات

Apigee Edge با کد وضعیت 400 Bad Request با کد خطا messaging.adaptors.http.flow.DecompressionFailureAtRequest مطابق مشخصات RFC زیر پاسخ می دهد:

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

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

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

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

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