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

Sie lesen gerade die Apigee Edge -Dokumentation.
Zur Apigee X -Dokumentation. info

Symptom

Die Clientanwendung erhält die Antwort HTTP 400 Bad Request mit der Meldung The plain HTTP request was sent to HTTPS port.

Fehlermeldung

Die Clientanwendung erhält den folgenden Antwortcode: 

HTTP/1.1 400 Bad Request

Gefolgt von der folgenden 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 TLS-konfigurierten virtuellen Host Der Client sendet eine HTTP-Anfrage an einen 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 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, aber stattdessen eine HTTP-Anfrage erhält.

Diagnose

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

  1. Prüfen Sie Ihre API-Anfrage und ob Sie eine HTTP-Anfrage für einen Hostalias stellen, der so konfiguriert ist, dass Anfragen nur über den sicheren Port 443 akzeptiert werden. Wenn ja, ist dies 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 Hostalias myorg-test.apigee.net über den sicheren Port 443 gesendet. Dies ist die Ursache für den 400 Bad Request Fehler.

Auflösung

Sie müssen prüfen, ob der Client HTTP anstelle von HTTPS verwendet, und die richtige Anfrage stellen, wie unten gezeigt:

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

So diagnostizieren Sie den Fehler mit dem Trace-Tool:

  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. In der Regel stammt die 400-Fehlerantwort vom Back-End-Server. Das heißt, Sie sehen die 400-Fehlerantwort in der Phase Response received from target server (Antwort vom Zielserver erhalten), wie unten gezeigt:

  6. Ermitteln Sie den Zielendpunkt, für den die Anfrage gestellt wurde, indem Sie im Trace auf das Symbol AX (Analysedaten aufgezeichnet) klicken.

  7. Notieren Sie sich die target.url, die das Protokoll, den Hostalias des Back-End-Servers und manchmal die Portnummer enthält. Der für die Ziel-URL verwendete Port ist 443 aber das Protokoll ist HTTP.
  8. Prüfen Sie die Definition des Zielendpunkts, um die Konfiguration zu verstehen.

  9. Prüfen Sie, ob der Host des Back-End-Servers sicher ist und einen sicheren Port wie 443 überwacht. Wenn Sie das Protokoll als http im Element <URL> verwenden, ist dies die Ursache für dieses Problem.

    Beispielkonfiguration des Zielendpunkts :

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

    Im obigen Beispiel verwenden Sie das HTTP-Protokoll, aber der verwendete Port ist der sichere Port 443. Dadurch antwortet der Back-End-Server mit 400 Bad Request und der Fehlermeldung The plain HTTP request was sent to HTTPS port.

Auflösung

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

    Beispielkonfiguration des Zielendpunkts :

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

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

    • Geben Sie keine sichere Portnummer wie 443 an.
    • Sie müssen die Portnummer überhaupt 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

    Beispielkonfiguration des Zielendpunkts :

    <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

So diagnostizieren Sie den Fehler mit dem Trace-Tool:

  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. In der Regel stammt die 400 -Fehlerantwort vom Back-End-Server. Das heißt, Sie sehen die 400 Fehlerantwort in der Phase Response received from target server (Antwort vom Zielserver erhalten), wie unten gezeigt:

  6. Ermitteln Sie den Zielendpunkt, für den die Anfrage gestellt wurde, indem Sie im Trace auf das Symbol AX (Analysedaten aufgezeichnet) klicken.

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

    In der obigen Trace-Datei ist target.name default. Das bedeutet, dass der für diese Anfrage verwendete Zielendpunkt der Standardendpunkt ist.

  8. Prüfen Sie die Definition des Zielendpunkts, um die Konfiguration zu verstehen.

    Beispielkonfiguration des Zielendpunkts :

    <?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 des Zielendpunkts zeigt, dass Sie einen Zielserver mit dem Namen faulty-target verwenden.

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

    • Edge-UI
    • Management API

Edge-UI

  1. Gehen Sie zu Apigee Edge > Verwaltung > Umgebungen > Zielserver.
  2. Wählen Sie den spezifischen Zielserver aus, der vom API-Proxy identifiziert wurde, 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 (z. B. 443) konfiguriert ist, aber SSL nicht aktiviert ist, ist dies die Ursache für dieses Problem.

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

Management API

  1. Führen Sie die API Zielserver abrufen aus, um die Details zur spezifischen Zielserverkonfiguration zu erhalten 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 (z. B. 443) konfiguriert ist, aber der SSLInfo Abschnitt nicht definiert oder nicht aktiviert ist, ist dies die Ursache für dieses Problem.

    Beispielkonfiguration des Zielservers :

    {
  "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 kein SSLInfo Konfigurationsblock vorhanden ist.

    Dadurch sendet der Message Processor von Apigee Edge HTTP-Anfragen an den sicheren Port 443. Daher erhalten Sie den Fehler 400 Bad Request mit der Meldung 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 aktivieren.

Dazu haben Sie folgende Möglichkeiten:

  • Edge-UI
  • Management API

Edge-UI

  1. Gehen Sie in der Edge-UI > Verwaltung > Umgebungen > Zielserver zum Zielserver.
  2. Wählen Sie den spezifischen 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 Option „SSL“ anklicken.
  4. Konfigurieren Sie Truststore, Ciphers und Protocols. (Nur falls erforderlich)

Management API

Konfigurieren Sie den Zielserver mit der Management API, wie in der Dokumentation Zielserverkonfiguration aktualisieren beschrieben.

Erfassen von Diagnoseinformationen erforderlich

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

  1. Wenn Sie ein Public Cloud-Nutzer sind, geben Sie die folgenden Informationen an:
    • Name der Organisation
    • Name der Umgebung
    • Name des API-Proxys
    • Vollständiger curl-Befehl zum Reproduzieren des Fehlers
    • Ausgabe des Trace-Tools (falls Sie sie für die fehlgeschlagene Anfrage erfassen konnten)
  2. Wenn Sie ein Private Cloud-Nutzer sind, geben Sie die folgenden Informationen an:
    • Vollständige Fehlermeldung
    • Name der Umgebung
    • API-Proxy-Bundle
    • Zielserverdefinition (wenn Sie in Ihrem Endpunkt einen Zielserver verwenden)
    • Ausgabe des Trace-Tools (falls Sie sie für die fehlgeschlagene Anfrage erfassen konnten)