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 نمی‌تواند payload را با استفاده از کدگذاری مشخص‌شده رمزگشایی کند، زیرا فرمت payload با کدگذاری مشخص‌شده در سربرگ Content-Encoding یکسان نیست.

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

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

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

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

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

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

تشخیص

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

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

   پیام خطا

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

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

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

      "faultstring":"Decompression failure at request"

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

   ردیابی

   برای اعتبارسنجی با استفاده از 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 است. با این حال، فایل درخواست request_payload.zip در قالب ZIP است. بنابراین، این درخواست با کد وضعیت 400 Bad Request و کد خطای messaging.adaptors.http.flow.DecompressionFailureAtRequest با شکست مواجه می‌شود.

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

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

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

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

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

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

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

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

      سناریوی شماره ۱: وقتی درخواست 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 به برنامه‌های کلاینت برمی‌گرداند.

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

      سناریوی شماره ۲: وقتی درخواست 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 در پیام خطای بالا نشان می‌دهند که payload درخواست با فرمت deflate ارسال نشده و با کدگذاری مشخص شده در هدر Content-Encoding مربوط به deflate مطابقت ندارد. بنابراین، Apigee Edge این استثنا را ایجاد می‌کند و کد وضعیت 400 با کد خطای messaging.adaptors.http.flow.DecompressionFailureAtRequest به برنامه‌های کلاینت برمی‌گرداند.

وضوح تصویر

1. اگر در جریان پروکسی API در Apigee Edge و در سرور backend نیازی به فشرده‌سازی payload درخواست نیست، هدر Content-Encoding را ارسال نکنید . اگر نیاز به فشرده‌سازی payload درخواست است، به مرحله ۲ بروید.
2. مطمئن شوید که برنامه کلاینت همیشه موارد زیر را ارسال می‌کند:
   • هر یک از کدگذاری‌های پشتیبانی‌شده به عنوان مقدار هدر Content-Encoding در درخواست
   • بار داده درخواست در قالب پشتیبانی‌شده توسط Apigee Edge با قالب کدگذاری مشخص‌شده در سربرگ Content-Encoding مطابقت دارد.
3. در مثالی که در بالا مورد بحث قرار گرفت، فایل درخواست (payload) با فرمت 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 نیاز دارید، به بخش «باید اطلاعات تشخیصی را جمع‌آوری کنید» بروید.

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

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

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

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