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

<ph type="x-smartling-placeholder"></ph> Vous consultez la documentation Apigee Edge.
Accédez à la page Documentation sur Apigee X. En savoir plus

Symptôme

L'application cliente reçoit une réponse HTTP 400 Bad Request contenant 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

Cette page est suivie 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 TLS Le client envoie une requête HTTP à un hôte virtuel TLS configuré Utilisateurs Edge de cloud public et privé
Requête HTTP envoyée à un point de terminaison cible configuré avec TLS Requête HTTP envoyée à un serveur backend compatible avec TLS dans le point de terminaison cible. Utilisateurs Edge de cloud public et privé
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 de cloud public et privé

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

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

Diagnostic

Ce problème se produisant sur <ph type="x-smartling-placeholder"></ph> point de terminaison nord et les requêtes API échouent lors de l'interaction du point d'entrée entre les application cliente et le routeur, ces messages d'erreur ne sont pas consignés dans le routeur NGINX les journaux d'accès. Par conséquent, ces demandes ne seront pas capturées dans des outils tels que la surveillance des API et l'outil Trace.

  1. Vérifiez votre requête API et voyez si vous envoyez 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 tel est le cas, qui est à l'origine 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 raison pour laquelle 400 Bad Request erreur.

Solution

Vous devez vérifier si le client utilise HTTP au lieu de HTTPS et envoyer la requête correcte en tant que 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
<ph type="x-smartling-placeholder">

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

Cette erreur se produit si vous avez mal configuré des requêtes HTTP vers un backend compatible TLS dans le point de terminaison cible d'un proxy d'API.

Diagnostic

<ph type="x-smartling-placeholder">

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

  1. Activez Trace dans l'interface utilisateur d'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ù la défaillance s'est produite.

  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 (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 AX. (Données analytiques enregistrées) dans la trace.

  7. Notez le fichier 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 écoute sur un port sécurisé tel que 443. Si vous utilisez le protocole http dans l'élément <URL>, alors qui est à l'origine 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 sécurisé port 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é ou compatible avec TLS, assurez-vous d'utiliser le protocole 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>
    <ph type="x-smartling-placeholder">

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

    • 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 un port non sécurisé standard
    • 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 du serveur cible incorrecte

Si le serveur cible est configuré avec un port sécurisé tel que 443 sans l'activer SSL, cela oblige le processeur de messages d'Apigee Edge à envoyer des requêtes HTTP à un réseau Serveur cible configuré pour TLS à l'origine de ce problème.

Diagnostic

<ph type="x-smartling-placeholder">

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

  1. Activez Trace dans l'interface utilisateur d'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ù la défaillance s'est produite.

  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 (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 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, 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ée faulty-target.

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

    • 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 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 SSL n'est pas activé, c'est la cause du problème.

    Comme vous pouvez le voir dans la capture d'écran ci-dessus, le port utilisé est 443, mais pas SSL activé pour ce port dans la configuration du serveur cible. Cela entraîne l'envoi du message d'Apigee Edge Processeur pour envoyer les requêtes HTTP au port sécurisé 443. Par conséquent, l'erreur 400 Bad Request avec le message The plain HTTP request was sent to HTTPS port.

API de gestion

  1. Exécutez la <ph type="x-smartling-placeholder"></ph> Obtenir l'API du serveur cible 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 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, cela explique pourquoi ce problème.

    Exemple de configuration de 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 il n'existe pas de bloc de configuration SSLInfo.

    Le processeur de messages d'Apigee Edge envoie donc des requêtes HTTP au port sécurisé. 443 Vous obtenez donc 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é avec le protocole TLS, vous devez activer SSL pour le serveur le serveur cible.

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 > Environnements > Serveurs cibles
  2. Choisissez le serveur cible spécifique, puis cliquez sur Modifier.
  3. Si votre serveur cible est sécurisé et utilise un port tel que 443, activez SSL en cochez la case à côté de l'option SSL.
  4. Configurez Truststore, Ciphers et Protocoles. (uniquement si nécessaire)

API de gestion

Utilisez l'API de gestion pour configurer le serveur cible comme décrit dans les <ph type="x-smartling-placeholder"></ph> Mettre à jour la documentation sur la configuration du serveur cible

Vous devez collecter des informations de diagnostic

Si le problème persiste alors que vous avez suivi les instructions ci-dessus, rassemblez les informations suivantes : de diagnostic, puis contactez l'assistance Apigee Edge.

  1. Si vous êtes un utilisateur de Cloud public, fournissez les informations suivantes: <ph type="x-smartling-placeholder">
      </ph>
    • Nom de l'organisation
    • Nom de l'environnement
    • Nom de proxy d'API
    • Exécutez la commande curl pour reproduire l'erreur
    • Résultats 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 Private Cloud, fournissez les informations suivantes: <ph type="x-smartling-placeholder">
      </ph>
    • 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ésultats de l'outil Trace (si vous avez réussi à effectuer une capture pour la requête ayant échoué)