400 - طلب غير صالح - إلغاء الضغط وفك التشفير

أنت تعرض مستندات Apigee Edge.
انتقل إلى مستندات Apigee X.
معلومات

المشكلة

يحصل تطبيق العميل على رمز حالة HTTP 400 Bad Request مع رمز الخطأ. messaging.adaptors.http.flow.DecompressionFailureAtRequest كردّ على واجهة برمجة التطبيقات الاتصالات.

رسالة الخطأ

يحصل تطبيق العميل على رمز الاستجابة التالي:

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 تنسيق الحمولة المتوقّعة
ترميز فردي برنامج gzip

تنسيق gzip لنظام التشغيل Unix

عرض تنسيق RFC1952 GZIP

ترميز فردي انكماش

يستخدم هذا التنسيق بنية zlib مع خوارزمية ضغط الانكماش.

عرض RFC1950 RFC1951.

الترميز المتعدد

الترميز المتعدد

على سبيل المثال، في الحالات التي يتم فيها التشفير مرتين، يمكن أن يكون ذلك مما يلي:

  • gzip، الانكماش
  • gzip، gzip
  • تفريغ، gzip
  • انكماش، انكماش
يتم تطبيق ترميز متعدد على الحمولة بالترتيب المحدد كما يظهر في العنوان.

فيما يلي الأسباب المحتملة لهذا الخطأ:

السبب الوصف إرشادات استكشاف الأخطاء وإصلاحها التي تنطبق على
عدم تطابق تنسيق حمولة الطلب مع الترميز المحدّد في العنوان Content-Encoding تنسيق حمولة الطلب الذي أرسله العميل إما غير مرمّز أو لا يتطابق مع الترميز المحدَّد في العنوان Content-Encoding مستخدمو Edge Public و Private Cloud

خطوات التشخيص الشائعة

استخدِم إحدى الأدوات/الأساليب التالية لتشخيص هذا الخطأ:

مراقبة واجهة برمجة التطبيقات

لتشخيص الخطأ باستخدام مراقبة واجهة برمجة التطبيقات:

  1. سجِّل الدخول إلى واجهة مستخدم Apigee Edge كمستخدم باستخدام الدور المناسب.
  2. انتقِل إلى المؤسسة التي تريد التحقيق في المشكلة فيها.

  3. انتقل إلى تحليل > مراقبة واجهة برمجة التطبيقات > التحقيق في الصفحة.
  4. اختَر الفترة الزمنية المحدّدة التي لاحظت فيها الأخطاء.
  5. تأكَّد من ضبط فلتر الخادم الوكيل على الكل.
  6. ارسم رمز الخطأ مقابل الوقت.
  7. اختَر خلية تتضمّن رمز الخطأ messaging.adaptors.http.flow.DecompressionFailureAtRequest باعتباره كما هو موضح أدناه:

    ( عرض صورة أكبر)

  8. معلومات عن رمز الخطأ يتم عرض messaging.adaptors.http.flow.DecompressionFailureAtRequest كما هو موضّح أدناه:

    ( عرض صورة أكبر)

  9. انقر على عرض السجلات ووسِّع الصف الذي يتعذّر عرضه مع ظهور الخطأ 400.

    ( عرض صورة أكبر)

  10. من نافذة السجلات، يُرجى ملاحظة التفاصيل التالية:
    • رمز الحالة: 400
    • مصدر الخطأ: proxy
    • رمز الخطأ: messaging.adaptors.http.flow.DecompressionFailureAtRequest.
  11. إذا كانت قيمة المصدر الخطأ proxy، فإنها تشير إلى أن تنسيق حمولة الطلب لم يتطابق مع ترميز معتمد المحدد في عنوان Content-Encoding.

أداة التتبُّع

لتشخيص الخطأ باستخدام أداة التتبُّع:

  1. تفعيل جلسة التتبُّع وإمّا:
    1. انتظِر إلى أن يحدث الخطأ 400 Bad Request.
    2. إذا كان بإمكانك إعادة إنتاج المشكلة، عليك طلب بيانات من واجهة برمجة التطبيقات وإعادة إنتاجها. 400 Bad Request
  2. تأكَّد من تفعيل عرض كل FlowInfos:

  3. اختَر أحد الطلبات التي تعذّر تنفيذها وافحص عملية التتبُّع.
  4. يمكنك التنقّل خلال مراحل عملية التتبُّع المختلفة وتحديد موضع التعذُّر حدث.
  5. ستجد عادةً الخطأ في التدفق بعد مرحلة استلام الطلب من العميل كما هو موضّح أدناه:

    ( عرض صورة أكبر)

  6. دوِّن قيم السمات من عملية التتبُّع:

    • الخطأ: Decompression failure at request
    • error.class: com.apigee.rest.framework.BadRequestException
    • error.cause: Not in GZIP format

    يوضِّح error.cause أنّ حمولة الطلب ليست بتنسيق GZIP. يعني هذا أنّ Apigee Edge كانت تتوقع أن تكون حمولة الطلب بتنسيق GZIP. لأنّه سيتم تحديدها في عنوان Content-Encoding.

  7. تحديد قيمة عنوان الطلب Content-Encoding ولإجراء ذلك، انتقِل إلى المرحلة تم تلقّي الطلب من العميل كما هو موضّح أدناه:

    ( عرض صورة أكبر)

    لاحظ أن قيمة رأس الطلب Content-Encoding هي فعلاً gzip

    يوضح تتبُّع النموذج أعلاه أنّ الترميز المحدَّد في عنوان الطلب تم gzip ميزة Content-Encoding. إلا أن حمولة الطلب ليس بتنسيق GZIP. لذلك، لا يمكن لـ Apigee فك ضغط الحمولة باستخدام gzip وتعرض الخطأ Decompression failure at request.

  8. دوِّن رمز الحالة ورسالة الخطأ التي يعرضها Apigee Edge من خلال الانتقال إلى

    إلى مرحلة تم إرسال الرد إلى العميل في التتبع كما هو موضح أدناه:

    ( عرض صورة أكبر)

    يُرجى ملاحظة التفاصيل التالية من عملية التتبُّع:

    • رمز الحالة: 400 Bad Request.
    • محتوى الخطأ: {"fault":{"faultstring":"Decompression failure at request","detail":{"errorcode":"messaging.adaptors.http.flow.DecompressionFailureAtRequest"}}}
  9. انتقِل إلى مرحلة AX (بيانات مسجَّلة في "إحصاءات Google") في عملية التتبُّع. وانقر عليه.

  10. مرِّر لأسفل إلى قسم تفاصيل المرحلة وعناوين الخطأ تحديد قيمتَي X-Apigee-fault-code وX-Apigee-fault-code كما هو موضح أدناه:

    ( عرض صورة أكبر)

  11. ستظهر لك قيمتا X-Apigee-fault-code وX-Apigee-fault-code. باسم messaging.adaptors.http.flow.DecompressionFailureAtRequest policy، ما يشير إلى أنّ تنسيق حمولة الطلب لم يتطابق مع المحدد في العنوان Content-Encoding.
    عناوين الردود القيمة
    X-Apigee-fault-code messaging.adaptors.http.flow.DecompressionFailureAtRequest
    X-Apigee-fault-source policy

NGINX

لتشخيص الخطأ باستخدام سجلات وصول NGINX:

  1. إذا كنت مستخدمًا للسحابة الإلكترونية الخاص، يمكنك استخدام سجلات وصول 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 تتطابق مع القيمة messaging.adaptors.http.flow.DecompressionFailureAtRequest، ثم تحديد قيمة X-Apigee-fault-source.

    نموذج الخطأ 400 من سجلّ وصول NGINX:

    يتضمن إدخال النموذج أعلاه من سجل وصول NGINX القيم التالية X-Apigee-fault-code وX-Apigee-fault-code

    عناوين الردود القيمة
    X-Apigee-fault-code messaging.adaptors.http.flow.DecompressionFailureAtRequest
    X-Apigee-fault-source policy

السبب: تنسيق حمولة الطلب لا يتطابق مع الترميز المحدّد في عنوان ترميز المحتوى

بشكل تلقائي، تفكك Apigee Edge دائمًا ضغط الحمولة إذا كان عنوان الطلب يحتوي Content-Encoding على عنصر صالح بترميز متوافق. لذا، يُتوقع أن يكون تنسيق حمولة الطلب يجب أن يتطابق مع الترميز المحدّد في عنوان الطلب Content-Encoding. في حال عدم التطابق، سيظهر هذا الخطأ.

التشخيص

  1. حدِّد رمز الخطأ ومصدر الخطأ للخطأ الذي تم رصده باستخدام واجهة برمجة التطبيقات. سجلات الوصول للمراقبة أو أداة التتبع أو 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. ومع ذلك، فإن حمولة الطلب request_payload.zip بتنسيق ZIP. لذلك، لا يزال هذا الطلب تعذَّر تطبيق رمز الحالة 400 Bad Request ورمز الخطأ: messaging.adaptors.http.flow.DecompressionFailureAtRequest

    سجلات معالج الرسائل

    للتحقق من صحة استخدام سجلات معالج الرسائل:

    إذا كنت مستخدمًا خاصًا في السحابة الإلكترونية، يمكنك استخدام سجلات "معالج الرسائل" لتحديد المعلومات الأساسية حول أخطاء HTTP 400.

    1. تحديد معرّف الرسالة للطلب الذي تعذّر إكماله باستخدام واجهة برمجة التطبيقات مراقبة، وأداة التتبع، أو سجلات الوصول إلى NGINX كما هو موضح في خطوات التشخيص الشائعة.
    2. ابحث عن معرِّف الرسالة في سجل معالج الرسائل:

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

    3. سيظهر لك أحد الاستثناءات التالية:

      السيناريو الأول

      السيناريو 1: عندما يحتوي طلب واجهة برمجة التطبيقات على العنوان 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: عندما يحتوي طلب واجهة برمجة التطبيقات على العنوان 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 في رسالة الخطأ أعلاه تشير إلى عدم إرسال حمولة الطلب ولا يتطابق هذا التنسيق مع الترميز المحدد في ملف تعريف الارتباط موضع الانكماش: Content-Encoding ولذلك، لا شك في أنّ Apigee Edge تطرح الاستثناء وتعرض رمز الحالة 400 مع رمز الخطأ messaging.adaptors.http.flow.DecompressionFailureAtRequest إلى تطبيقات العميل.

الدقة

  1. في حال لم تكن هناك حاجة إلى حمولة الطلبات المضغوطة في مسار خادم وكيل واجهة برمجة التطبيقات في Apigee Edge وفي خادم الخلفية، لا تضبط الرأس 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 التالي المواصفات:

المواصفات
RFC 7231، الفقرة 6.5.1
RFC 7231، الفقرة 3.1.2.2

إذا كنت بحاجة إلى مزيد من المساعدة من Apigee، يُرجى الانتقال إلى . يجب جمع معلومات التشخيص.

يجب جمع معلومات التشخيص

اجمع معلومات التشخيص التالية، ثم تواصَل مع فريق دعم Apigee Edge:

إذا كنت من مستخدمي Cloud Public، يُرجى تقديم المعلومات التالية:

  • اسم المؤسسة
  • اسم البيئة
  • اسم الخادم الوكيل لواجهة برمجة التطبيقات
  • إكمال الأمر curl المُستخدَم لإعادة إنتاج الخطأ 400
  • ملف تتبُّع طلبات البيانات من واجهة برمجة التطبيقات

إذا كنت مستخدمًا للسحابة الإلكترونية الخاصة، قدِّم المعلومات التالية:

  • ظهور رسالة خطأ كاملة للطلبات التي تعذّر تنفيذها
  • اسم البيئة
  • حزمة الخادم الوكيل لواجهة برمجة التطبيقات
  • ملف تتبُّع طلبات البيانات من واجهة برمجة التطبيقات
  • سجلّات وصول 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