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

Vous consultez la documentation d'Apigee Edge.
Consultez la documentation Apigee X. en savoir plus

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 obtient 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 envoyée à un hôte virtuel configuré par TLS Le client envoie une requête HTTP à un hôte virtuel configuré par TLS. Utilisateurs Edge Public and Private Cloud
Requête HTTP envoyée à un point de terminaison cible configuré par TLS Requête HTTP envoyée à un serveur backend compatible TLS dans le point de terminaison cible. Utilisateurs Edge Public and Private Cloud
Configuration du serveur cible incorrecte Le serveur cible est configuré avec le port sécurisé 443, mais le protocole SSL n'est pas activé. Utilisateurs Edge Public and Private Cloud

Cause: requête HTTP envoyée à un hôte virtuel configuré par 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 et reçoit une requête HTTP à la place.

Diagnostic

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

  1. Vérifiez votre requête API et vérifiez si vous effectuez une requête HTTP pour un alias d'hôte configuré pour n'accepter les requêtes que sur le port sécurisé 443. Si oui, c'est 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 envoyée à l'alias d'hôte myorg-test.apigee.net sur le port sécurisé 443. C'est la cause de l'erreur 400 Bad Request.

Résolution

Vous devez vérifier si le client utilise HTTP au lieu de HTTPS et envoyer la requête appropriée, 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 envoyée à un point de terminaison cible configuré par TLS

Cette erreur se produit si vous avez mal configuré les requêtes HTTP à destination d'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'interface utilisateur Apigee pour le proxy d'API concerné.
  2. Envoyez des requêtes au proxy d'API.
  3. Sélectionnez l'une des requêtes API qui ont é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, la réponse d'erreur 400 s'affiche dans la phase 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 (Données analytiques enregistrées) dans la trace.

  7. Notez le champ 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. Examinez 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 en tant que http dans l'élément <URL>, c'est la cause de ce problème.

    Exemple de configuration d'un 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 ainsi avec 400 Bad Request et le message d'erreur The plain HTTP request was sent to HTTPS port.

Résolution

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

    Exemple de configuration d'un point de terminaison cible:

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

  2. Si votre serveur backend n'est pas sécurisé:

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

    Exemple de configuration d'un 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 activer SSL, le processeur de messages d'Apigee Edge envoie des requêtes HTTP à un serveur cible sécurisé ou configuré par 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'interface utilisateur Apigee pour le proxy d'API concerné.
  2. Envoyez des requêtes au proxy d'API.
  3. Sélectionnez l'une des requêtes API qui ont é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. Vous verrez donc la réponse d'erreur 400 dans la phase 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 (Données analytiques enregistrées) dans la trace.

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

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

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

    Exemple de configuration d'un 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 de 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 vérifier la configuration du serveur cible à l'aide de l'une des méthodes suivantes:

    • Interface utilisateur périphérique
    • API de gestion

Interface utilisateur périphérique

  1. Accédez à Apigee Edge > Admin > Environnements > Serveurs cibles.
  2. Choisissez le serveur cible spécifique identifié à partir du proxy d'API et cliquez sur Modifier.
  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é, c'est la cause de ce problème.

    Comme vous pouvez le voir dans la capture d'écran ci-dessus, le port utilisé est 443, mais le protocole SSL n'est pas activé pour ce port dans la configuration du serveur cible. Ainsi, le processeur de messages d'Apigee Edge envoie 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 Obtenir le serveur cible pour obtenir des informations sur la configuration spécifique du serveur cible, 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 Private Cloud:

    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, c'est 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 sortie ci-dessus, nous pouvons constater que le port utilisé pour la connexion cible est 443, mais qu'il n'existe pas de bloc de configuration SSLInfo.

    Ainsi, le processeur de messages d'Apigee Edge envoie 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.

Résolution

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

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

  • Interface utilisateur périphérique
  • API de gestion

Interface utilisateur périphérique

  1. Accédez au serveur cible sur Edge UI > Admin > Environments > Target Servers (Interface utilisateur Edge > Admin > Environnements > Serveurs cibles).
  2. Choisissez le serveur cible souhaité, puis cliquez sur Modifier.
  3. Si votre serveur cible est sécurisé et utilise un port tel que 443, activez SSL en cochant la case correspondant à l'option SSL.
  4. Configurez le Truststore, les Ciphers et les 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, puis contactez l'assistance Apigee Edge.

  1. Si vous êtes un utilisateur de Cloud public, fournissez les informations suivantes :
    • Le nom de l'organisation.
    • Nom de l'environnement
    • Nom de proxy d'API
    • Exécuter la commande curl pour reproduire l'erreur
    • Résultat de l'outil Trace (si vous avez réussi à effectuer une capture pour la requête ayant échoué)
  2. Si vous êtes un utilisateur de cloud privé, fournissez les informations suivantes :
    • Message d'erreur complet observé
    • Nom de l'environnement
    • Groupe de proxys 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 réussi à effectuer une capture pour la requête ayant échoué)