Error 400 de solicitud incorrecta - DescompresiónFailureAtRequest

Estás viendo la documentación de Apigee Edge.
Ve a la Documentación de Apigee X. información

Síntoma

La aplicación cliente obtiene un código de estado HTTP de 400 Bad Request con el código de error. messaging.adaptors.http.flow.DecompressionFailureAtRequest como respuesta a la API llamadas.

Mensaje de error

La aplicación cliente obtiene el siguiente código de respuesta:

HTTP/1.1 400 Bad Request

Además, es posible que veas un mensaje de error similar al que se muestra a continuación:

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

Causas posibles

Este error ocurre solo si se cumplen estas condiciones:

• La codificación especificada en el encabezado de la solicitud HTTP Content-Encoding es válida y compatibles con Apigee Edge,

PERO

• El formato de carga útil que envía el cliente como parte de la solicitud HTTP no Debe coincidir con el formato de codificación especificado en el encabezado Content-Encoding

Esto se debe a que Apigee Edge no puede decodificar la carga útil con la codificación especificada, ya que la de la carga útil no tiene el mismo formato que la codificación especificada en el Encabezado Content-Encoding.

Estos son algunos ejemplos de valores Content-Encoding admitidos y cómo Apigee Edge se espera que esté el formato de la carga útil en esos casos:

Situación	Content-Encoding	Formato de carga útil esperado
Codificación única	gzip	El formato gzip de Unix Consulta Formato GZIP RFC1952.
Codificación única	disminuir	Este formato usa la estructura zlib con el algoritmo de compresión de desinflación. Consulta RFC1950 y RFC1951.
Codificación múltiple	Codificación múltiple Por ejemplo, en los casos en que la codificación se hace dos veces, puede ser: gzip, deflate gzip y gzip deflate, gzip desinflar, reducir	Se aplicó una codificación múltiple a la carga útil en el orden especificado, tal como aparece en el encabezado.

Las posibles causas de este error son las siguientes:

Causa	Descripción	Instrucciones de solución de problemas aplicables para
El formato de la carga útil de la solicitud no coincide con la codificación especificada en el encabezado de codificación de contenido	El formato de la carga útil de la solicitud que envió el cliente no está codificado o no está coincida con la codificación especificada en el encabezado Content-Encoding.	Usuarios perimetrales de nubes públicas y privadas

Pasos comunes de diagnóstico

Usa una de las siguientes herramientas o técnicas para diagnosticar este error:

Causa: El formato de carga útil de la solicitud no coincide con la codificación especificada en el encabezado Codificación de contenido

De forma predeterminada, Apigee Edge siempre descomprime la carga útil si el encabezado de la solicitud Content-Encoding contiene un valor válido y un la codificación compatible. Por lo tanto, se espera que el formato de la carga útil de la solicitud debe coincidir con la codificación especificada en el encabezado de solicitud Content-Encoding. Si hay una discrepancia, verás este error.

Diagnóstico

1. Determina el código de error y la fuente de errores del error observado con la API. Monitoring, la herramienta de seguimiento o los registros de acceso de NGINX como se explica en Pasos comunes del diagnóstico.
2. Si el Código de error es messaging.adaptors.http.flow.DecompressionFailureAtRequest y las La fuente del error tiene el valor policy o proxy, y luego este indica que la solicitud enviada por la aplicación cliente tiene una carga útil que no coincide con el la codificación compatible especificada en el encabezado de la solicitud Content-Encoding.

3. Puedes determinar la falta de coincidencia como parte de la solicitud HTTP mediante una de las siguientes opciones: métodos:

   Mensaje de error

   Para validar con el mensaje de error, haz lo siguiente:

   1. Si tienes acceso al mensaje de error completo que recibiste de Apigee Edge, consulta faultstring.

      Ejemplo de mensaje de error:

      "faultstring":"Decompression failure at request"
      

   2. En el mensaje de error anterior, muestra "Decompression failure at request", lo que implica que la solicitud no se pudo descomprimir mediante la codificación especificada en el Content-Encoding.

   Trace

   Para validar con Trace, sigue estos pasos:

   1. Determina el valor del encabezado de la solicitud Content-Encoding y el la propiedad error.cause con Trace como se explica en Pasos comunes del diagnóstico.

   2. Los valores del seguimiento de muestra son los siguientes:

      • Codificación del contenido: gzip
      • error.cause: Not in GZIP format

      El valor en el encabezado de solicitud Content-Encoding es gzip. Sin embargo, la carga útil de la solicitud no está en formato GZIP. (como lo indica error.cause). Por lo tanto, Apigee Edge responde con 400 Bad Request y código de error messaging.adaptors.http.flow.DecompressionFailureAtRequest

   Solicitud real

   Para validar con la solicitud real, haz lo siguiente:

   Si tienes acceso a la solicitud real que realizó el cliente y realiza los siguientes pasos:

   1. Determina el valor que se pasa al encabezado de la solicitud Content-Encoding.
   2. Determinar el formato de la carga útil enviada como parte de la solicitud

   3. Si el valor del encabezado Content-Encoding está en la lista de codificación compatible, pero el formato de la carga útil de la solicitud no es debe coincidir con la codificación especificada en el encabezado Content-Encoding esa es la causa del problema.

      Solicitud de muestra:

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

      La solicitud de ejemplo anterior envía el valor gzip al Content-Encoding, que es un la codificación compatible en Apigee Edge. Sin embargo, la carga útil de la solicitud request_payload.zip está en formato ZIP. Por lo tanto, esta solicitud falla con un código de estado 400 Bad Request y el código de error: messaging.adaptors.http.flow.DecompressionFailureAtRequest

   Registros del procesador de mensajes

   Para realizar la validación con los registros de Message Processor, haz lo siguiente:

   Si eres un usuario de la nube privada, puedes usar los registros de Message Processor. para determinar la información clave sobre los errores 400 de HTTP.

   1. Determinar el ID del mensaje de la solicitud con errores usando la supervisión de API, la herramienta Trace o NGINX, como se explica en Pasos de diagnóstico comunes.

   2. Busca el ID del mensaje en el registro de Message Processor:

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

   3. Verás una de las siguientes excepciones:

      Situación 1

      Situación 1: Cuando la solicitud a la API tiene el encabezado 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
      

      La línea java.util.zip.ZipException: Not in GZIP format del mensaje de error anterior indica que la solicitud la carga útil no se envía en formato GZIP, aunque la Content-Encoding se especifica como gzip. Por lo tanto, Apigee Edge arroja la excepción y devuelve un código de estado 400 con el código de falla messaging.adaptors.http.flow.DecompressionFailureAtRequest a las aplicaciones cliente.

      Situación 2

      Situación 2: Cuando la solicitud a la API tiene el encabezado 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)
      

      Las líneas java.util.zip.ZipException: incorrect header check y Caused by: java.util.zip.DataFormatException: incorrect header check en el mensaje de error anterior indican que la carga útil de la solicitud no se envió en reducir el formato y no coincide con la codificación especificada en el Content-Encoding encabezado de reducción. Por lo tanto, Apigee Edge arroja la excepción y muestra un código de estado 400 con código de falla messaging.adaptors.http.flow.DecompressionFailureAtRequest a las aplicaciones cliente.

Solución

1. Si no se necesita la carga útil de solicitud comprimida en el flujo del proxy de API en Apigee Edge y en el servidor de backend, no pases el encabezado Content-Encoding. Si es necesario comprimir la carga útil de la solicitud, ve al paso 2.
2. Asegúrate de que la aplicación cliente siempre envíe lo siguiente:
   • Cualquiera de los Codificación admitida como el valor del encabezado Content-Encoding en el solicitud
   • La carga útil de la solicitud en el formato admitido para Apigee Edge coincide con la codificación formato especificado en el encabezado Content-Encoding
3. En el ejemplo anterior, la carga útil de la solicitud está en formato ZIP, pero el encabezado de la solicitud especifica Content-Encoding: gzip. Para solucionar el problema, envía la solicitud encabezado como Content-Encoding: gzip y la carga útil de la solicitud también en gzip formato:

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

Especificación

Apigee Edge responde con el código de estado 400 Bad Request con el código de error. messaging.adaptors.http.flow.DecompressionFailureAtRequest según el siguiente RFC específicas:

Especificación
RFC 7231, sección 6.5.1
RFC 7231, sección 3.1.2.2

Si aún necesitas asistencia del equipo de asistencia de Apigee, ve a Se debe recopilar información de diagnóstico.

Se debe recopilar información de diagnóstico

Obtén la siguiente información de diagnóstico y, luego, comunícate con el equipo de asistencia de Apigee Edge:

Si eres usuario de la nube pública, proporciona la siguiente información:

• Nombre de la organización
• Nombre del entorno
• Nombre del proxy de API
• Completa el comando curl que se usa para reproducir el error 400
• Archivo de seguimiento de las solicitudes a la API

Si eres un usuario de la Nube privada, proporciona la siguiente información:

• Mensaje de error completo observado para las solicitudes fallidas
• Nombre del entorno
• Paquete de proxy de API
• Archivo de seguimiento de las solicitudes a la API

• Registros de acceso de NGINX /opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log

  Dónde: ORG, ENV y PORT# se reemplazan por valores reales.

• Registros del sistema del procesador de mensajes /opt/apigee/var/log/edge-message-processor/logs/system.log