400 Ungültige Anfrage – einfache HTTP-Anfrage an HTTPS-Port gesendet

<ph type="x-smartling-placeholder"></ph> Sie sehen die Dokumentation zu Apigee Edge.
Gehen Sie zur Apigee X-Dokumentation. Weitere Informationen

Symptom

Die Clientanwendung empfängt eine HTTP 400 Bad Request-Antwort mit der Nachricht The plain HTTP request was sent to HTTPS port.

Fehlermeldung

Die Clientanwendung erhält den folgenden Antwortcode: 

HTTP/1.1 400 Bad Request

Darauf folgt die folgende HTML-Fehlerseite: 

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

Mögliche Ursachen

Ursache Beschreibung Anleitungen zur Fehlerbehebung gelten für
HTTP-Anfrage an einen mit TLS konfigurierten virtuellen Host Der Client sendet eine HTTP-Anfrage an einen virtuellen TLS-Host, der konfiguriert ist Edge-Nutzer von öffentlichen und privaten Clouds
HTTP-Anfrage an einen durch TLS konfigurierten Zielendpunkt HTTP-Anfrage an einen TLS-fähigen Backend-Server im Zielendpunkt. Edge-Nutzer von öffentlichen und privaten Clouds
Falsche Zielserverkonfiguration Der Zielserver ist mit dem sicheren Port 443 konfiguriert, aber SSL ist nicht aktiviert. Edge-Nutzer von öffentlichen und privaten Clouds

Ursache: HTTP-Anfrage an einen mit TLS konfigurierten virtuellen Host

Dieser Fehler tritt auf, wenn ein Client versucht, eine Verbindung zu einer API auf Apigee und den genannten Der virtuelle Host ist für die Verwendung von SSL konfiguriert und erhält stattdessen eine HTTP-Anfrage.

Diagnose

Da dieses Problem auf der <ph type="x-smartling-placeholder"></ph> nach Norden ausgerichtet und die API-Anfragen schlagen an der Interaktion zwischen dem Clientanwendung und Router haben, werden diese Fehlermeldungen nicht im NGINX-Router protokolliert. Zugriffslogs. Daher werden diese Anfragen nicht in Tools wie API-Monitoring und das Trace-Tool.

  1. Überprüfen Sie Ihre API-Anfrage und stellen Sie fest, ob Sie eine HTTP-Anfrage für einen Host-Alias senden, der ist so konfiguriert, dass Anfragen nur über den sicheren Port 443 akzeptiert werden. Wenn ja, ist das die Ursache des Problems.

    Beispiel für eine falsche API-Anfrage:

    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. In der obigen Beispielanfrage wird eine HTTP-Anfrage an den Host-Alias gesendet. myorg-test.apigee.net auf dem sicheren Port 443. Dies ist der Grund für den 400 Bad Request Fehler.

Auflösung

Sie müssen überprüfen, ob der Client HTTP anstelle von HTTPS verwendet, und die richtige Anfrage wie folgt stellen: (siehe unten):

Beispiel für eine API-Anfrage:

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

oder

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

Ursache: HTTP-Anfrage an einen mit TLS konfigurierten Zielendpunkt

Dieser Fehler tritt auf, wenn Sie HTTP-Anfragen an ein TLS-fähiges Back-End falsch konfiguriert haben im Zielendpunkt eines API-Proxys.

Diagnose

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

Führen Sie die folgenden Schritte aus, um den Fehler mithilfe des Trace-Tools zu diagnostizieren:

  1. Aktivieren Sie Trace in der Apigee-UI für den betroffenen API-Proxy.
  2. Stellen Sie Anfragen an den API-Proxy.
  3. Wählen Sie eine der API-Anfragen aus, die mit dem Antwortcode 400 fehlgeschlagen sind.
  4. Gehen Sie die verschiedenen Phasen durch und ermitteln Sie, wo der Fehler aufgetreten ist.

  5. Normalerweise wird die Fehlerantwort 400 vom Back-End-Server angezeigt. Das heißt, Sie sehen die Fehlerantwort 400 in der Phase Antwort erhalten vom Zielserver wie unten gezeigt:

  6. Klicken Sie auf den AX, um den Zielendpunkt zu ermitteln, für den die Anfrage gesendet wurde. (Analytics-Daten aufgezeichnet) im Trace.

  7. Beachten Sie die URL target.url, die das Protokoll, den Host-Alias des Back-End-Servers und manchmal auch die Portnummer. Der für die Die Ziel-URL ist 443, aber das Protokoll ist HTTP.
  8. Sehen Sie sich die Definition des Zielendpunkts an, um die Konfiguration zu verstehen.

  9. Prüfe, ob der Backend-Serverhost sicher ist und einen sicheren Port wie 443 überwacht. Wenn Sie das Protokoll als http im <URL>-Element verwenden, gibt ist das die Ursache des Problems.

    Beispielkonfiguration für Zielendpunkt:

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

    Das obige Beispiel zeigt, dass Sie das HTTP-Protokoll verwenden, der verwendete Port jedoch sicher ist. Port 443. Dadurch antwortet der Backend-Server mit 400 Bad Request und die Fehlermeldung The plain HTTP request was sent to HTTPS port.

Auflösung

  1. Wenn Ihr Backend-Server sicher/TLS-fähig ist, achten Sie darauf, dass Sie das Protokoll als https im <URL>-Element des Zielendpunkts, wie in im folgenden Beispiel:

    Beispielkonfiguration für Zielendpunkt:

    <HTTPTargetConnection>
    <Properties/>
    <URL>https://somehost.org:443/get</URL>
</HTTPTargetConnection>
    <ph type="x-smartling-placeholder">

  2. Wenn Ihr Back-End-Server nicht sicher ist, dann:

    • Erwähnen Sie nicht die Nummer des sicheren Ports wie 443.
    • Sie müssen die Portnummer überhaupt nicht angeben, wenn Ihr Backend-Server ein nicht sicherer Standardport
    • Geben Sie die Portnummer an, wenn Sie einen anderen nicht sicheren Port verwenden. Beispiel: 9080

    Beispielkonfiguration für Zielendpunkt:

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

or

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

Ursache: Falsche Zielserverkonfiguration

Wenn der Zielserver mit einem sicheren Port wie 443 konfiguriert ist, ohne die Funktion zu aktivieren SSL haben, sendet der Message Processor von Apigee Edge HTTP-Anfragen an eine sichere oder Ein TLS-konfigurierter Zielserver, der zu diesem Problem führt.

Diagnose

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

Führen Sie die folgenden Schritte aus, um den Fehler mithilfe des Trace-Tools zu diagnostizieren:

  1. Aktivieren Sie Trace in der Apigee-UI für den betroffenen API-Proxy.
  2. Stellen Sie Anfragen an den API-Proxy.
  3. Wählen Sie eine der API-Anfragen aus, für die der Antwortcode 400 zurückgegeben wurde.
  4. Gehen Sie die verschiedenen Phasen durch und ermitteln Sie, wo der Fehler aufgetreten ist.

  5. Normalerweise wird die Fehlerantwort 400 vom Back-End-Server angezeigt. Das heißt, Sie sehen die Fehlerantwort 400 in der Phase Antwort erhalten vom Zielserver wie unten gezeigt:

  6. Klicken Sie auf den AX, um den Zielendpunkt zu ermitteln, für den die Anfrage gesendet wurde. (Analytics-Daten aufgezeichnet) im Trace.

  7. Beachten Sie den Namen target.name, der den Namen des Zielendpunkts darstellt.

    In der obigen Beispiel-Trace-Datei hat target.name den Wert default. Das bedeutet, dass der für diese Anfrage verwendete Zielendpunkt der Standardwert ist.

  8. Sehen Sie sich die Definition des Zielendpunkts an, um die Konfiguration zu verstehen.

    Beispielkonfiguration für Zielendpunkt:

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

    Das obige Beispiel für eine Zielendpunktkonfiguration zeigt, dass Sie einen Zielserver verwenden. mit dem Namen faulty-target.

  9. Sobald Sie den Namen des Zielservers kennen, können Sie eine der folgenden Methoden verwenden, um überprüfen Sie die Zielserverkonfiguration:

    • Edge-Benutzeroberfläche
    • Management API

Edge-Benutzeroberfläche

  1. Gehen Sie zu Apigee Edge > Verwaltung > Umgebungen > Zielserver.
  2. Wählen Sie den vom API-Proxy angegebenen Zielserver aus und klicken Sie auf Bearbeiten.
  3. Prüfen Sie den für den Zielserver angegebenen Port und die SSL-Informationen.

  4. Wenn der Zielserver mit einem sicheren Port konfiguriert ist (z. B. 443), aber SSL nicht aktiviert ist, ist das die Ursache des Problems.

    Wie Sie im Screenshot oben sehen können, wird als Port 443 verwendet, SSL ist jedoch nicht für diesen Port in der Zielserverkonfiguration aktiviert ist. Dies führt zur Meldung von Apigee Edge Prozessor zum Senden von HTTP-Anfragen an den sicheren Port 443. Daher erhalten Sie die Fehler 400 Bad Request mit der Meldung The plain HTTP request was sent to HTTPS port.

Management API

  1. Führen Sie den <ph type="x-smartling-placeholder"></ph> Zielserver-API abrufen, um Details zur spezifischen Zielserverkonfiguration abzurufen wie unten dargestellt:

    Public Cloud-Nutzer:

    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"

    Private Cloud-Nutzer:

    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. Prüfen Sie den für den Zielserver angegebenen Port und die SSL-Informationen.

  3. Wenn der Zielserver mit einem sicheren Port konfiguriert ist (z. B. 443), aber wenn der Abschnitt SSLInfo nicht definiert oder nicht aktiviert ist, dieses Problem.

    Beispiel für eine Zielserverkonfiguration:

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

    In der obigen Beispielausgabe sehen wir, dass der für die Zielverbindung verwendete Port 443, aber es gibt keinen SSLInfo-Konfigurationsblock.

    Dies führt dazu, dass der Message Processor von Apigee Edge HTTP-Anfragen an den sicheren Port sendet 443 Daher wird der Fehler 400 Bad Request mit der Meldung angezeigt, The plain HTTP request was sent to HTTPS port.

Auflösung

Wenn Ihr Zielserver sicher oder TLS-konfiguriert ist, müssen Sie SSL für den jeweiligen Zielserver.

Dazu können Sie eine der folgenden Optionen verwenden:

  • Edge-Benutzeroberfläche
  • Management API

Edge-Benutzeroberfläche

  1. Navigieren Sie zum Zielserver über Edge UI > Verwaltung > Umgebungen > Zielserver.
  2. Wählen Sie den gewünschten Zielserver aus und klicken Sie auf Bearbeiten.
  3. Wenn Ihr Zielserver sicher ist und einen Port wie 443 verwendet, aktivieren Sie SSL, indem Sie das Kontrollkästchen neben der SSL-Option.
  4. Konfigurieren Sie Truststore, Ciphers und Protokolle. (Nur falls erforderlich)

Management API

Konfigurieren Sie den Zielserver mithilfe der Verwaltungs-API wie in den <ph type="x-smartling-placeholder"></ph> Aktualisieren Sie die Dokumentation zur Zielserverkonfiguration.

Erfassen von Diagnoseinformationen erforderlich

Wenn das Problem trotz Befolgung der obigen Anleitung weiterhin besteht, stellen Sie Folgendes zusammen: Diagnoseinformationen und wenden Sie sich dann an den Apigee Edge-Support.

  1. Wenn Sie ein Nutzer von Public Cloud sind, geben Sie die folgenden Informationen an: <ph type="x-smartling-placeholder">
      </ph>
    • Name der Organisation
    • Name der Umgebung
    • Name des API-Proxys
    • Führen Sie den curl-Befehl aus, um den Fehler zu reproduzieren.
    • Trace-Tool-Ausgabe (falls Sie bei der fehlgeschlagenen Anfrage erfassen konnten)
  2. Wenn Sie ein Private Cloud-Nutzer sind, geben Sie die folgenden Informationen an: <ph type="x-smartling-placeholder">
      </ph>
    • Vollständige Fehlermeldung erkannt
    • Name der Umgebung
    • API-Proxy-Bundle
    • Zielserverdefinition (wenn Sie einen Zielserver an Ihrem Endpunkt verwenden)
    • Trace-Tool-Ausgabe (falls Sie bei der fehlgeschlagenen Anfrage erfassen konnten)