400 Requête incorrecte - Requête HTTP simple envoyée au port HTTPS

Vous consultez la documentation Apigee Edge.
Accédez à la documentation**Apigee X**. info

Problème constaté

L'application cliente reçoit une réponse HTTP 400 Bad Request avec le message The plain HTTP request was sent to HTTPS port.

Message d'erreur

L'application cliente reçoit le code de réponse suivant : 

HTTP/1.1 400 Bad Request

Suivi de la page d'erreur HTML ci-dessous : 

<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>

Causes possibles

Cause Description Instructions de dépannage applicables
Requête HTTP adressée à un hôte virtuel configuré pour TLS Le client envoie une requête HTTP à un hôte virtuel configuré pour TLS. Utilisateurs du cloud public et privé Edge
Requête HTTP adressée à un point de terminaison cible configuré pour TLS Requête HTTP adressée à un serveur backend compatible TLS dans le point de terminaison cible. Utilisateurs du cloud public et privé Edge
Configuration incorrecte du serveur cible Le serveur cible est configuré avec le port sécurisé 443, mais SSL n'est pas activé. Utilisateurs du cloud public et privé Edge

Cause : requête HTTP adressée à un hôte virtuel configuré pour TLS

Cette erreur se produit lorsqu'un client tente de se connecter à une API sur Apigee et que l'hôte virtuel mentionné est configuré pour utiliser SSL, mais reçoit une requête HTTP à la place.

Diagnostic

Étant donné que ce problème se produit sur le point de terminaison Northbound et que les requêtes API échouent au point d'interaction entre l' application cliente et le routeur, ces messages d'erreur ne sont pas enregistrés dans les journaux d'accès du routeur NGINX. Par conséquent, ces requêtes ne seront pas capturées dans des outils tels qu'API Monitoring et l'outil Trace.

  1. Vérifiez votre requête API et déterminez si vous effectuez une requête HTTP pour un alias d'hôte qui est configuré pour n'accepter les requêtes que sur le port sécurisé 443. Si c'est le cas, il s'agit de la cause du problème.

    Exemple de requête API incorrecte :

    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. Dans l'exemple de requête ci-dessus, notez qu'une requête HTTP est adressée à l'alias d'hôte myorg-test.apigee.net sur le port sécurisé 443. Il s'agit de la cause de l' 400 Bad Request erreur.

Solution

Vous devez vérifier si le client utilise HTTP au lieu de HTTPS et effectuer la requête correcte comme indiqué ci-dessous :

Exemple de requête API :

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

ou

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

Cause : requête HTTP adressée à un point de terminaison cible configuré pour TLS

Cette erreur se produit si vous avez configuré de manière incorrecte des requêtes HTTP adressées à un serveur backend compatible TLS dans le point de terminaison cible d'un proxy d'API.

Diagnostic

Pour diagnostiquer l'erreur à l'aide de l'outil Trace, procédez comme suit :

  1. Activez Trace dans l'UI d'Apigee pour le proxy d'API concerné.
  2. Effectuez des requêtes auprès du proxy d'API.
  3. Sélectionnez l'une des requêtes API qui a échoué avec le code de réponse 400.
  4. Parcourez les différentes phases et déterminez où l'échec s'est produit.

  5. En règle générale, la réponse d'erreur 400 provient du serveur backend. Autrement dit, vous verrez la réponse d'erreur 400 dans la phase Response received from target server (Réponse reçue du serveur cible), comme indiqué ci-dessous :

  6. Déterminez le point de terminaison cible pour lequel la requête a été effectuée en cliquant sur l'icône AX (Analytics Data Recorded, Données d'analyse enregistrées) dans la trace.

  7. Notez la target.url, qui contient le protocole, l'alias d'hôte du serveur backend, et parfois le numéro de port. Le port utilisé pour l' URL cible est 443 mais le protocole est HTTP.
  8. Consultez la définition du point de terminaison cible pour comprendre la configuration.

  9. Vérifiez que l'hôte du serveur backend est sécurisé et qu'il écoute sur un port sécurisé tel que 443. Si vous utilisez le protocole http dans l'élément <URL>, il s'agit de la cause de ce problème.

    Exemple de configuration du point de terminaison cible :

    <?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>

    L'exemple ci-dessus montre que vous utilisez le protocole HTTP, mais que le port utilisé est le port sécurisé 443. Le serveur backend répond alors avec 400 Bad Request et le message d'erreur The plain HTTP request was sent to HTTPS port.

Solution

  1. Si votre serveur backend est sécurisé/compatible TLS, assurez-vous d'utiliser le protocole comme https dans l'élément <URL> du point de terminaison cible, comme indiqué dans l'exemple suivant :

    Exemple de configuration du point de terminaison cible :

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

  2. Si votre serveur backend n'est pas sécurisé, procédez comme suit :

    • Ne mentionnez pas le numéro de port sécurisé, tel que 443.
    • Vous n'avez pas besoin de mentionner le numéro de port si votre serveur backend écoute sur un port non sécurisé standard.
    • Mentionnez le numéro de port si vous utilisez un autre port non sécurisé, par exemple : 9080

    Exemple de configuration du point de terminaison cible :

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

or

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

Cause : configuration incorrecte du serveur cible

Si le serveur cible est configuré avec un port sécurisé tel que 443 sans que SSL soit activé, le processeur de messages d'Apigee Edge envoie des requêtes HTTP à un serveur cible sécurisé ou configuré pour TLS, ce qui entraîne ce problème.

Diagnostic

Pour diagnostiquer l'erreur à l'aide de l'outil Trace, procédez comme suit :

  1. Activez Trace dans l'UI d'Apigee pour le proxy d'API concerné.
  2. Effectuez des requêtes auprès du proxy d'API.
  3. Sélectionnez l'une des requêtes API qui a échoué avec le code de réponse 400.
  4. Parcourez les différentes phases et déterminez où l'échec s'est produit.

  5. En règle générale, la réponse d'erreur 400 provient du serveur backend. Autrement dit, vous verrez la réponse d'erreur 400 dans la phase Response received from target server (Réponse reçue du serveur cible), comme indiqué ci-dessous :

  6. Déterminez le point de terminaison cible pour lequel la requête a été effectuée en cliquant sur l'icône AX (Analytics Data Recorded, Données d'analyse enregistrées) dans la trace.

  7. Notez le target.name, qui représente le nom du point de terminaison cible.

    Dans l'exemple de fichier de trace ci-dessus, le target.name est default. Cela indique que le point de terminaison cible utilisé pour cette requête est celui par défaut.

  8. Consultez la définition du point de terminaison cible pour comprendre la configuration.

    Exemple de configuration du point de terminaison cible :

    <?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>

    L'exemple de configuration du point de terminaison cible ci-dessus montre que vous utilisez un serveur cible nommé faulty-target.

  9. Une fois que vous disposez du nom du serveur cible, vous pouvez utiliser l'une des méthodes suivantes pour vérifier la configuration du serveur cible :

    • UI Edge
    • API de gestion

UI Edge

  1. Accédez à Apigee Edge > Admin > Environments > Target Servers (Apigee Edge > Admin > Environnements > Serveurs cibles).
  2. Choisissez le serveur cible spécifique identifié à partir du proxy d'API, puis cliquez sur Edit.
  3. Vérifiez le port spécifié pour le serveur cible et les informations SSL.

  4. Si le serveur cible est configuré avec un port sécurisé (par exemple, 443), mais que SSL n'est pas activé, il s'agit de la cause de ce problème.

    Comme vous pouvez le voir dans la capture d'écran ci-dessus, le port utilisé est 443, mais SSL n'est pas activé pour ce port dans la configuration du serveur cible. Le processeur de messages d'Apigee Edge envoie alors des requêtes HTTP au port sécurisé 443. Par conséquent, vous obtenez l' erreur 400 Bad Request avec le message The plain HTTP request was sent to HTTPS port.

API de gestion

  1. Exécutez l'API Get target server pour obtenir les détails de la configuration du serveur cible spécifique comme indiqué ci-dessous :

    Utilisateur du cloud public :

    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"

    Utilisateur du cloud privé :

    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. Vérifiez le port spécifié pour le serveur cible et les informations SSL.

  3. Si le serveur cible est configuré avec un port sécurisé (par exemple, 443), mais que la section SSLInfo n'est pas définie ou n'est pas activée, il s'agit de la cause de ce problème.

    Exemple de configuration du serveur cible :

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

    Dans l'exemple de résultat ci-dessus, nous pouvons voir que le port utilisé pour la connexion cible est 443, mais qu'il n'existe aucun bloc de configuration SSLInfo.

    Le processeur de messages d'Apigee Edge envoie alors des requêtes HTTP au port sécurisé 443. Par conséquent, vous obtenez l'erreur 400 Bad Request avec le message The plain HTTP request was sent to HTTPS port.

Solution

Si votre serveur cible est sécurisé ou configuré pour TLS, vous devez activer SSL pour le serveur cible spécifique cible.

Pour ce faire, utilisez l'une des options suivantes :

  • UI Edge
  • API de gestion

UI Edge

  1. Accédez au serveur cible dans UI Edge > Admin > Environments > Target Servers (UI Edge > Admin > Environnements > Serveurs cibles).
  2. Choisissez le serveur cible spécifique, puis cliquez sur Edit (Modifier).
  3. Si votre serveur cible est sécurisé et utilise un port tel que 443, activez SSL en cochant la case à côté de l'option SSL.
  4. Configurez Truststore , Ciphers (Chiffrements) et Protocols (Protocoles). (Uniquement si nécessaire)

API de gestion

Utilisez l'API de gestion pour configurer le serveur cible, comme décrit dans la documentation Mettre à jour la configuration du serveur cible.

Vous devez collecter des informations de diagnostic

Si le problème persiste, même après avoir suivi les instructions ci-dessus, rassemblez les informations de diagnostic suivantes et contactez l'assistance Apigee Edge.

  1. Si vous êtes un utilisateur du cloud public, fournissez les informations suivantes :
    • Nom de l'organisation
    • Nom de l'environnement
    • Nom de proxy d'API
    • Commande curl complète pour reproduire l'erreur
    • Résultat de l'outil Trace (si vous avez pu capturer la requête ayant échoué)
  2. Si vous êtes un utilisateur du cloud privé, fournissez les informations suivantes :
    • Message d'erreur complet observé
    • Nom de l'environnement
    • Bundle de proxy d'API
    • Définition du serveur cible (si vous utilisez un serveur cible dans votre point de terminaison)
    • Résultat de l'outil Trace (si vous avez pu capturer la requête ayant échoué)