Solicitud incorrecta 400: Solicitud HTTP sin formato enviada al puerto HTTPS

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 recibe una respuesta HTTP 400 Bad Request con el mensaje. The plain HTTP request was sent to HTTPS port

Mensaje de error

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

HTTP/1.1 400 Bad Request

A continuación, se muestra la siguiente página de error de HTML: 

<html>
<head><title>400 The plain HTTP request was sent to HTTPS port</title></head>
<body>
<center><h1>400 Bad Request</h1></center>
<center>The plain HTTP request was sent to HTTPS port</center>
</body>
</html>

Causas posibles

Causa Descripción Instrucciones de solución de problemas aplicables para
Solicitud HTTP a un host virtual configurado con TLS El cliente envía una solicitud HTTP a un host virtual configurado con TLS Usuarios perimetrales de nubes públicas y privadas
Solicitud HTTP a un extremo de destino configurado con TLS Solicitud HTTP realizada a un servidor de backend habilitado con TLS en el extremo de destino. Usuarios perimetrales de nubes públicas y privadas
Configuración incorrecta del servidor de destino El servidor de destino está configurado con el puerto seguro 443, pero SSL no está habilitado. Usuarios perimetrales de nubes públicas y privadas

Causa: solicitud HTTP a un host virtual configurado con TLS

Este error ocurre cuando un cliente intenta conectarse a una API en Apigee y los el host virtual está configurado para usar SSL y recibe una solicitud HTTP en su lugar.

Diagnóstico

Dado que este problema ocurre en el El extremo hacia el norte y las solicitudes a la API fallan en la interacción del punto de entrada entre los en la aplicación cliente y el router, estos mensajes de error no se registran en el router NGINX de acceso a los datos. Por lo tanto, estas solicitudes no se registrarán en herramientas como API Monitoring y la herramienta Trace.

  1. Verifica tu solicitud a la API y observa si haces una solicitud HTTP para un alias de host que está configurada para aceptar solicitudes solo en el puerto seguro 443. Si es así, entonces esa es la causa del problema.

    Ejemplo de solicitud a la API incorrecta:

    curl http://org-test.apigee.net:443/400-demo

    <html>
<head><title>400 The plain HTTP request was sent to HTTPS port</title></head>
<body>
<center><h1>400 Bad Request</h1></center>
<center>The plain HTTP request was sent to HTTPS port</center>
<hr><center>server</center>
</body>
</html>
  2. En la solicitud de ejemplo anterior, ten en cuenta que se realiza una solicitud HTTP al alias del host. myorg-test.apigee.net en el puerto seguro 443. Esta es la causa de que 400 Bad Request error.

Solución

Debes verificar si el cliente usa HTTP en lugar de HTTP y hacer la solicitud correcta como como se muestra a continuación:

Ejemplo de solicitud a la API:

curl https://org-test.apigee.net:443/400-demo

o

curl https://org-test.apigee.net/400-demo

< HTTP/1.1 200 OK
< Date: Thu, 25 Feb 2021 13:01:43 GMT
< Content-Type: text/xml;charset=UTF-8
< Content-Length: 403
< Connection: keep-alive
< Server: gunicorn/19.9.0
< Access-Control-Allow-Origin: *
< Access-Control-Allow-Credentials: true

Causa: solicitud HTTP a un extremo de destino configurado con TLS

Este error ocurre si configuraste de forma incorrecta solicitudes HTTP a un backend habilitado con TLS en el extremo de destino de un proxy de API.

Diagnóstico

Sigue estos pasos para diagnosticar el error con la herramienta Trace:

  1. Habilita Trace en la IU de Apigee para el proxy de API afectado.
  2. Realiza solicitudes al proxy de API.
  3. Selecciona una de las solicitudes a la API que fallaron con el código de respuesta 400.
  4. Navega por las distintas fases y determina dónde ocurrió la falla.

  5. Por lo general, verás que la respuesta de error 400 proviene del servidor de backend. Es decir, verás la respuesta de error 400 en la fase Respuesta recibida del servidor de destino, como se muestra a continuación:

  6. Haz clic en el ícono AX para determinar el extremo de destino para el que se realizó la solicitud. (Datos registrados de Analytics) del seguimiento.

  7. Observa que target.url contiene el protocolo, el alias del host del servidor de backend, y, a veces, el número de puerto. El puerto que se usa para el la URL de destino es 443, pero el protocolo es HTTP.
  8. Revisa la definición del extremo de destino para comprender la configuración.

  9. Verifica que el host del servidor de backend sea seguro y que escuche en un puerto seguro, como 443. Si usas el protocolo como http en el elemento <URL>, entonces esa es la causa del problema.

    Ejemplo de configuración del extremo de destino:

    <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<TargetEndpoint name="default">
    <Description/>
    <FaultRules/>
    <PreFlow name="PreFlow">
        <Request/>
        <Response/>
    </PreFlow>
    <PostFlow name="PostFlow">
        <Request/>
        <Response/>
    </PostFlow>
    <Flows/>
    <HTTPTargetConnection>
        <Properties/>
        <URL>http://somehost.org:443/get</URL>
    </HTTPTargetConnection>
</TargetEndpoint>

    En el ejemplo anterior, se muestra que estás usando el protocolo HTTP, pero el puerto que se usa es seguro puerto 443. Esto hace que el servidor de backend responda con 400 Bad Request y el mensaje de error The plain HTTP request was sent to HTTPS port

Solución

  1. Si tu servidor backend está seguro o habilitado para TLS, asegúrate de usar el protocolo como https en el elemento <URL> del extremo de destino, como se muestra en el siguiente ejemplo:

    Ejemplo de configuración del extremo de destino:

    <HTTPTargetConnection>
    <Properties/>
    <URL>https://somehost.org:443/get</URL>
</HTTPTargetConnection>

  2. Si tu servidor de backend no es seguro, sucederá lo siguiente:

    • No menciones el número de puerto seguro, como 443.
    • No debes mencionar el número de puerto si tu servidor backend escucha un puerto no seguro estándar
    • Menciona el número de puerto si usas cualquier otro puerto no seguro, por ejemplo: 9080

    Ejemplo de configuración del extremo de destino:

    <HTTPTargetConnection>
    <Properties/>
    <URL>http://somehost.org/get</URL>
</HTTPTargetConnection>

or

<HTTPTargetConnection>
    <Properties/>
    <URL>http://somehost.org:9080/get</URL>
</HTTPTargetConnection>

Causa: Configuración incorrecta del servidor de destino

Si el servidor de destino está configurado con un puerto seguro, como 443, sin habilitar SSL, luego hace que el procesador de mensajes de Apigee Edge envíe solicitudes HTTP a un servidor El servidor de destino configurado con TLS genera este problema.

Diagnóstico

Sigue estos pasos para diagnosticar el error con la herramienta Trace:

  1. Habilita Trace en la IU de Apigee para el proxy de API afectado.
  2. Realiza solicitudes al proxy de API.
  3. Selecciona una de las solicitudes a la API que fallaron con el código de respuesta 400.
  4. Navega por las distintas fases y determina dónde ocurrió la falla.

  5. Por lo general, verás que la respuesta de error 400 proviene del servidor de backend. Es decir, verás la respuesta de error 400 en la fase Respuesta recibida del servidor de destino, como se muestra a continuación:

  6. Haz clic en el ícono AX para determinar el extremo de destino para el que se realizó la solicitud. (Datos registrados de Analytics) del seguimiento.

  7. Ten en cuenta el valor target.name, que representa el nombre del extremo de destino.

    En el archivo de registro de ejemplo anterior, target.name es default. Esto indica que el extremo de destino usado para esta solicitud es el predeterminado.

  8. Revisa la definición del extremo de destino para comprender la configuración.

    Ejemplo de configuración del extremo de destino:

    <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<TargetEndpoint name="default">
    <Description/>
    <FaultRules/>
    <PreFlow name="PreFlow">
        <Request/>
        <Response/>
    </PreFlow>
    <PostFlow name="PostFlow">
        <Request/>
        <Response/>
    </PostFlow>
    <Flows/>
    <HTTPTargetConnection>
        <Properties/>
        <LoadBalancer>
        <Server name="faulty-target"/>
        </LoadBalancer>
    </HTTPTargetConnection>
</TargetEndpoint>

    El ejemplo de configuración del extremo de destino anterior muestra que estás usando un servidor de destino con el nombre faulty-target.

  9. Una vez que tengas el nombre del servidor de destino, puedes usar uno de los siguientes métodos para verifica la configuración del servidor de destino:

    • IU de Edge
    • API de Management

IU de Edge

  1. Navega a Apigee Edge > Administrador > Entornos > Servidores de destino.
  2. Elige el servidor de destino específico identificado desde el proxy de API y haz clic en Editar.
  3. Verifica el puerto especificado para el servidor de destino y la información de SSL.

  4. Si el servidor de destino está configurado con un puerto seguro (por ejemplo: 443), pero SSL no está habilitada, esa es la causa del problema.

    Como puedes ver en la captura de pantalla anterior, el puerto que se usa es 443, pero SSL no es el único. habilitado para ese puerto en la configuración del servidor de destino. Esto provoca que el mensaje de Apigee Procesador que envía solicitudes HTTP al puerto seguro 443. Por lo tanto, obtienes el error 400 Bad Request con el mensaje The plain HTTP request was sent to HTTPS port.

API de Management

  1. Ejecuta el Obtén la API del servidor de destino para obtener los detalles sobre la configuración específica del servidor de destino. como se muestra a continuación:

    Usuario de la nube pública:

    curl -v 'https://api.enterprise.apigee.com/v1/organizations/ORG_NAME/environments/ENV_NAME>/targetservers/TARGET_SERVER_NAME' \
-H "Content-Type:application/xml" \
-H "Authorization:Bearer $TOKEN"

    Usuario de la nube privada:

    curl -v 'http://MANAGEMENT_IP:8080/v1/organizations/ORG_NAME/environments/ENV_NAME/targetservers/TARGET_SERVER_NAME' \
-H "Content-Type:application/xml" \
-H "Authorization:Bearer $TOKEN"
  2. Verifica el puerto especificado para el servidor de destino y la información de SSL.

  3. Si el servidor de destino está configurado con un puerto seguro (por ejemplo: 443), pero la sección SSLInfo no está definida o habilitada, esa es la causa de este problema.

    Ejemplo de configuración del servidor de destino:

    {
  "host" : "somehost.org",
  "isEnabled" : true,
  "name" : "faulty-target",
  "port" : 443
}

    En el resultado de ejemplo anterior, podemos ver que el puerto que se usa para la conexión de destino es 443, pero no hay un bloque de configuración SSLInfo.

    Esto hace que el procesador de mensajes de Apigee Edge envíe solicitudes HTTP al puerto seguro. 443 Por lo tanto, aparece el error 400 Bad Request con el mensaje. The plain HTTP request was sent to HTTPS port

Solución

Si tu servidor de destino es seguro o está configurado con TLS, debes habilitar SSL para el servidor servidor de destino.

Puedes hacerlo con una de las siguientes opciones:

  • IU de Edge
  • API de Management

IU de Edge

  1. Navega al servidor de destino en la IU de Edge > Administrador > Entornos > Servidores de destino.
  2. Elige el servidor de destino específico y haz clic en Editar.
  3. Si tu servidor de destino es seguro y usa un puerto como 443, habilita SSL marcando la casilla junto a la opción SSL.
  4. Configura Truststore, Cifrados y Protocolos. (Solo si es necesario)

API de Management

Usa la API de Management para configurar el servidor de destino como se describe en el Actualiza la documentación de la configuración del servidor de destino.

Se debe recopilar información de diagnóstico

Si el problema persiste, incluso después de seguir las instrucciones anteriores, reúne la siguiente información de diagnóstico y, luego, comunícate con el equipo de asistencia de Apigee Edge.

  1. 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
    • Completar el comando curl para reproducir el error
    • Resultado de la herramienta de seguimiento (si pudiste capturar la solicitud con errores)
  2. Si eres usuario de la nube privada, proporciona la siguiente información:
    • Se observó un mensaje de error completo
    • Nombre del entorno
    • Paquete de proxy de API
    • Definición del servidor de destino (si usas el servidor de destino en tu extremo)
    • Resultado de la herramienta de seguimiento (si pudiste capturar la solicitud con errores)