400 Неверный запрос — DecompressionFailureAtRequest

Вы просматриваете документацию Apigee Edge .
Перейдите в документацию Apigee X.info

Симптом

В ответ на вызовы API клиентское приложение получает 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.

По умолчанию Apigee Edge всегда распаковывает полезную нагрузку, если заголовок запроса Content-Encoding содержит допустимую и поддерживаемую кодировку . Поэтому ожидается, что формат полезной нагрузки запроса будет соответствовать кодировке, указанной в заголовке запроса Content-Encoding . В случае несоответствия вы получите эту ошибку.

Диагноз

1. Определите код ошибки и источник ошибки, используя мониторинг API, инструмент трассировки или журналы доступа 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 .

   След

   Для проверки с помощью трассировки:

   1. Определите значение заголовка запроса Content-Encoding и свойство error.cause с помощью трассировки , как описано в разделе «Общие шаги диагностики» .

   2. Значения, полученные из образца трассировки, следующие:

      • Content-Encoding: 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, инструмент трассировки или журналы доступа 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 и на бэкэнд-сервере нет необходимости в сжатом содержимом запроса, то не передавайте заголовок 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, перейдите по ссылке «Необходимо собрать диагностическую информацию» .

Необходимо собрать диагностическую информацию.

Соберите следующую диагностическую информацию, а затем свяжитесь со службой поддержки Apigee Edge :

Если вы являетесь пользователем публичного облака , предоставьте следующую информацию:

• Название организации
• Название среды
• Имя API-прокси
• Полная команда curl , использованная для воспроизведения ошибки 400
• Файл трассировки для запросов API

Если вы являетесь пользователем частного облака , предоставьте следующую информацию:

• Полное сообщение об ошибке, полученное для неудачных запросов.
• Название среды
• Пакет 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