400 Неверный запрос — 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.

По умолчанию 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 с помощью Trace , как описано в разделе Общие этапы диагностики .

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

      • Кодировка контента: gzip
      • ошибка.причина: 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 в приведенном выше сообщении об ошибке указывают на то, что полезные данные запроса не отправляются в дефляционном формате и не соответствуют кодировке. указанный в заголовке 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 :

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

• Название организации
• Имя среды
• Имя 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