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

Sie sehen die Dokumentation zu Apigee Edge.
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 mit TLS konfigurierten virtuellen Host Nutzer von Edge Public und Private Cloud
HTTP-Anfrage an einen TLS-konfigurierten Zielendpunkt HTTP-Anfrage an einen TLS-fähigen Back-End-Server im Zielendpunkt. Nutzer von Edge Public und Private Cloud
Falsche Zielserverkonfiguration Der Zielserver ist mit dem sicheren Port 443 konfiguriert, aber SSL ist nicht aktiviert. Nutzer von Edge Public und Private Cloud

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

Dieser Fehler tritt auf, wenn ein Client versucht, eine Verbindung zu einer API in Apigee herzustellen, und der erwähnte virtuelle Host für die Verwendung von SSL konfiguriert ist und stattdessen eine HTTP-Anfrage empfängt.

Diagnose

Da dieses Problem am Endpunkt Northbound auftritt und die API-Anfragen an der Interaktion des Einstiegspunkts zwischen der Clientanwendung und dem Router fehlschlagen, werden diese Fehlermeldungen nicht in den NGINX-Routerzugriffslogs protokolliert. Daher werden diese Anfragen nicht in Tools wie API-Monitoring und Trace erfasst.

  1. Prüfen Sie Ihre API-Anfrage und prüfen Sie, ob Sie eine HTTP-Anfrage für einen Hostalias senden, der so konfiguriert ist, dass nur Anfragen ü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. Beachten Sie in der obigen Beispielanfrage, dass eine HTTP-Anfrage an den Hostalias myorg-test.apigee.net über den sicheren Port 443 gesendet wird. Das ist die Ursache des Fehlers 400 Bad Request.

Auflösung

Du musst prüfen, ob der Client HTTP anstelle von HTTPS verwendet, und die richtige Anfrage wie unten gezeigt senden:

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

Ursache: HTTP-Anfrage an einen TLS-konfigurierten Zielendpunkt

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

Diagnose

Führen Sie die folgenden Schritte aus, um den Fehler mit dem Trace-Tool 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 fehlgeschlagene API-Anfrage mit dem Antwortcode 400 aus.
  4. Die verschiedenen Phasen durchgehen und herausfinden, wo der Fehler aufgetreten ist

  5. In der Regel sehen Sie die Fehlerantwort 400 vom Back-End-Server. Das heißt, Sie sehen die Fehlerantwort 400 in der Phase Antwort vom Zielserver erhalten, wie unten dargestellt:

  6. Bestimmen Sie den Zielendpunkt, für den die Anfrage gestellt wurde, indem Sie im Trace auf das Symbol AX (aufgezeichnete Analytics-Daten) klicken.

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

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

    Beispiel für eine Zielendpunktkonfiguration:

    <?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, aber der verwendete Port der sichere Port 443 ist. Dies führt dazu, dass der Back-End-Server mit 400 Bad Request und der Fehlermeldung The plain HTTP request was sent to HTTPS port antwortet.

Auflösung

  1. Wenn dein Back-End-Server sicher/TLS-fähig ist, musst du das Protokoll als https im Element <URL> des Zielendpunkts verwenden, wie im folgenden Beispiel gezeigt:

    Beispiel für eine Zielendpunktkonfiguration:

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

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

    • Erwähnen Sie nicht die Nummer des sicheren Ports wie 443.
    • Sie müssen die Portnummer gar nicht angeben, wenn Ihr Back-End-Server einen nicht sicheren Standardport überwacht.
    • Geben Sie die Portnummer an, wenn Sie einen anderen nicht sicheren Port verwenden, z. B. 9080

    Beispiel für eine Zielendpunktkonfiguration:

    <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 SSL zu aktivieren, sendet der Message Processor von Apigee Edge HTTP-Anfragen an einen sicheren oder TLS-konfigurierten Zielserver, was zu diesem Problem führt.

Diagnose

Führen Sie die folgenden Schritte aus, um den Fehler mit dem Trace-Tool 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 fehlgeschlagenen API-Anfragen mit dem Antwortcode 400 aus.
  4. Die verschiedenen Phasen durchgehen und herausfinden, wo der Fehler aufgetreten ist

  5. In der Regel sehen Sie die Fehlerantwort 400 vom Back-End-Server. Das heißt, Sie sehen die Fehlerantwort 400 in der Phase Antwort vom Zielserver erhalten, wie unten dargestellt:

  6. Bestimmen Sie den Zielendpunkt, für den die Anfrage gestellt wurde, indem Sie im Trace auf das Symbol AX (aufgezeichnete Analytics-Daten) klicken.

  7. Beachten Sie die Datei target.name, die für den Namen des Zielendpunkts steht.

    Im obigen Beispiel für die Trace-Datei lautet der target.name default. Dies gibt an, dass der für diese Anfrage verwendete Zielendpunkt der Standardendpunkt ist.

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

    Beispiel für eine Zielendpunktkonfiguration:

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

    Die obige Beispielkonfiguration für den Zielendpunkt zeigt, dass Sie einen Zielserver mit dem Namen faulty-target verwenden.

  9. Sobald Sie den Namen des Zielservers kennen, können Sie die Konfiguration des Zielservers mit einer der folgenden Methoden prüfen:

    • Edge-Benutzeroberfläche
    • Management API

Edge-Benutzeroberfläche

  1. Gehen Sie zu Apigee Edge > Admin > Environments > Target Servers (Apigee Edge > Admin > Umgebungen > Zielserver).
  2. Wählen Sie den vom API-Proxy identifizierten 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 für das Problem.

    Wie Sie im Screenshot oben sehen können, wird als Port 443 verwendet, aber SSL ist in der Zielserverkonfiguration für diesen Port nicht aktiviert. Dadurch sendet der Message Processor von Apigee Edge HTTP-Anfragen an den sicheren Port 443. Daher wird der Fehler 400 Bad Request mit der Meldung The plain HTTP request was sent to HTTPS port angezeigt.

Management API

  1. Führen Sie die Get target server API aus, um die Details zur spezifischen Zielserverkonfiguration abzurufen, wie unten gezeigt:

    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 der Abschnitt SSLInfo nicht definiert oder aktiviert ist, ist das die Ursache für 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 ist, aber es gibt keinen SSLInfo-Konfigurationsblock.

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

Auflösung

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

Dazu stehen Ihnen folgende Optionen zur Verfügung:

  • Edge-Benutzeroberfläche
  • Management API

Edge-Benutzeroberfläche

  1. Rufen Sie den Zielserver unter Edge-UI > Admin > Umgebungen > Zielserver auf.
  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 Kästchen neben der SSL-Option anklicken.
  4. Konfigurieren Sie Truststore, Ciphers und Protokolle. (Nur falls erforderlich)

Management API

Verwenden Sie die Management API, um den Zielserver zu konfigurieren, wie in der Dokumentation Zielserverkonfiguration aktualisieren beschrieben.

Erfassen von Diagnoseinformationen erforderlich

Wenn das Problem auch nach Befolgen der obigen Anleitung weiterhin besteht, stellen Sie die folgenden Diagnoseinformationen zusammen und wenden Sie sich an den Apigee Edge-Support.

  1. Wenn Sie die öffentliche Cloud nutzen, geben Sie die folgenden Informationen an:
    • 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 (wenn Sie die fehlgeschlagene Anfrage erfassen konnten)
  2. Wenn Sie die Private Cloud nutzen, geben Sie die folgenden Informationen an:
    • Vollständige Fehlermeldung festgestellt
    • Name der Umgebung
    • API-Proxy-Bundle
    • Zielserverdefinition (wenn Sie auf Ihrem Endpunkt einen Zielserver verwenden)
    • Trace-Tool-Ausgabe (wenn Sie die fehlgeschlagene Anfrage erfassen konnten)