400 Nieprawidłowe żądanie – zwykły wniosek HTTP wysłany do portu HTTPS

Przeglądasz dokumentację Apigee Edge.
Otwórz dokumentację Apigee X. Informacje

Krótki opis problemu

Aplikacja kliencka otrzymuje odpowiedź HTTP 400 Bad Request z komunikatem The plain HTTP request was sent to HTTPS port.

Komunikat o błędzie

Aplikacja kliencka pobiera ten kod odpowiedzi: 

HTTP/1.1 400 Bad Request

Po tej stronie wyświetla się poniższa strona błędu HTML: 

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

Możliwe przyczyny

Przyczyna Opis Instrukcje rozwiązywania problemów dotyczące
Żądanie HTTP do hosta wirtualnego skonfigurowanego w TLS Klient wysyła żądanie HTTP do hosta wirtualnego skonfigurowanego TLS Użytkownicy chmury publicznej i prywatnej usługi Edge
Żądanie HTTP do docelowego punktu końcowego skonfigurowanego w TLS Żądanie HTTP wysłane do serwera backendu z obsługą TLS w docelowym punkcie końcowym. Użytkownicy chmury publicznej i prywatnej usługi Edge
Nieprawidłowa konfiguracja serwera docelowego Serwer docelowy jest skonfigurowany z bezpiecznym portem 443, ale SSL nie jest włączone. Użytkownicy chmury publicznej i prywatnej usługi Edge

Przyczyna: żądanie HTTP do hosta wirtualnego skonfigurowanego w TLS

Ten błąd występuje, gdy klient próbuje połączyć się z interfejsem API w Apigee, a wspomniany host wirtualny jest skonfigurowany do używania protokołu SSL i zamiast tego otrzymuje żądanie HTTP.

Diagnostyka

Ponieważ ten problem występuje w punkcie końcowym Northbound, a żądania do interfejsu API kończą się niepowodzeniem w trakcie interakcji między aplikacją kliencką a routerem, te komunikaty o błędach nie są logowane w logach dostępu do routera NGINX. Dlatego żądania te nie będą rejestrowane w narzędziach takich jak monitorowanie interfejsów API czy narzędzie do śledzenia.

  1. Zweryfikuj żądanie do interfejsu API i sprawdź, czy wysyłasz żądanie HTTP dla aliasu hosta, który jest skonfigurowany tak, aby akceptować żądania tylko z bezpiecznego portu 443. Jeśli tak, to ono jest przyczyną problemu.

    Przykładowe nieprawidłowe żądanie do interfejsu API:

    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. W tym przykładowym żądaniu HTTP zostanie wysłane żądanie HTTP do aliasu hosta myorg-test.apigee.net na bezpiecznym porcie 443. To jest przyczyna błędu 400 Bad Request.

Rozdzielczość

Sprawdź, czy klient używa protokołu HTTP, a nie HTTP, i wyślij prawidłowe żądanie, jak pokazano poniżej:

Przykładowe żądanie do interfejsu API:

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

lub

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

Przyczyna: żądanie HTTP do docelowego punktu końcowego skonfigurowanego na podstawie TLS

Ten błąd występuje, jeśli żądania HTTP są nieprawidłowo skonfigurowane do serwera backendu z obsługą TLS w docelowym punkcie końcowym serwera proxy interfejsu API.

Diagnostyka

Aby zdiagnozować błąd za pomocą narzędzia do śledzenia:

  1. Włącz Trace w interfejsie Apigee dla serwera proxy interfejsu API, którego dotyczy problem.
  2. Wysyłaj żądania do serwera proxy interfejsu API.
  3. Wybierz jedno z żądań do interfejsu API, które zakończyły się niepowodzeniem z użyciem kodu odpowiedzi 400.
  4. Przejdź przez różne fazy i ustal, gdzie wystąpił błąd.

  5. Zazwyczaj odpowiedź o błędzie 400 jest wysyłana z serwera backendu. Oznacza to, że w etapie Odpowiedź otrzymana z serwera docelowego zobaczysz odpowiedź o błędzie 400, jak pokazano poniżej:

  6. Ustal docelowy punkt końcowy, do którego zgłoszono żądanie, klikając w logu czasu ikonę AX (rejestrowane dane Analytics).

  7. Zapisz wartość target.url, która zawiera protokół, alias hosta serwera backendu, a czasem numer portu. Port używany w docelowym adresie URL to 443, ale protokół to HTTP.
  8. Sprawdź definicję docelowego punktu końcowego, aby zrozumieć konfigurację.

  9. Sprawdź, czy host serwera backendu jest bezpieczny i nasłuchuje na bezpiecznym porcie, takim jak 443. Jeśli w elemencie <URL> używasz protokołu jako http, to jest przyczyną tego problemu.

    Przykładowa konfiguracja docelowego punktu końcowego:

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

    Powyższy przykład pokazuje, że używasz protokołu HTTP, ale użyty port to bezpieczny port 443. Spowoduje to wysłanie odpowiedzi serwera backendu 400 Bad Request i komunikatu o błędzie The plain HTTP request was sent to HTTPS port.

Rozdzielczość

  1. Jeśli Twój serwer backendu jest bezpieczny/włączony przez TLS, sprawdź, czy używasz protokołu jako https w elemencie <URL> docelowego punktu końcowego, jak pokazano w poniższym przykładzie:

    Przykładowa konfiguracja docelowego punktu końcowego:

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

  2. Jeśli serwer backendu jest niebezpieczny:

    • Nie wspominaj o numerze bezpiecznego portu, np. 443.
    • Jeśli serwer backendu nasłuchuje na standardowym niezabezpieczonym porcie, nie musisz podawać numeru portu.
    • Podaj numer portu, jeśli używasz innego niezabezpieczonego portu, na przykład: 9080

    Przykładowa konfiguracja docelowego punktu końcowego:

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

or

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

Przyczyna: nieprawidłowa konfiguracja serwera docelowego

Jeśli serwer docelowy jest skonfigurowany z zabezpieczonym portem, na przykład 443, bez włączania SSL, to powoduje, że procesor wiadomości Apigee Edge wysyła żądania HTTP do bezpiecznego serwera docelowego skonfigurowanego pod kątem protokołu TLS, co prowadzi do tego problemu.

Diagnostyka

Aby zdiagnozować błąd za pomocą narzędzia do śledzenia:

  1. Włącz Trace w interfejsie Apigee dla serwera proxy interfejsu API, którego dotyczy problem.
  2. Wysyłaj żądania do serwera proxy interfejsu API.
  3. Wybierz jedno z żądań do interfejsu API, które zakończyły się niepowodzeniem z użyciem kodu odpowiedzi 400.
  4. Przejdź przez różne fazy i ustal, gdzie wystąpił błąd.

  5. Zazwyczaj wyświetla się 400 odpowiedź o błędzie z serwera backendu. Oznacza to, że w etapie Odpowiedź otrzymana z serwera docelowego zobaczysz odpowiedź o błędzie 400, jak pokazano poniżej:

  6. Ustal docelowy punkt końcowy, do którego zgłoszono żądanie, klikając w logu czasu ikonę AX (rejestrowane dane Analytics).

  7. Zwróć uwagę na wartość target.name, która reprezentuje nazwę docelowego punktu końcowego.

    W przykładowym pliku śledzenia powyżej pole target.name to default. Wskazuje on, że docelowy punkt końcowy używany dla tego żądania jest domyślny.

  8. Sprawdź definicję docelowego punktu końcowego, aby zrozumieć konfigurację.

    Przykładowa konfiguracja docelowego punktu końcowego:

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

    Powyższa przykładowa konfiguracja docelowego punktu końcowego pokazuje, że używasz serwera docelowego o nazwie faulty-target.

  9. Po ustaleniu nazwy serwera docelowego możesz użyć jednej z tych metod, aby sprawdzić konfigurację serwera docelowego:

    • Interfejs Edge
    • interfejs API zarządzania Google Analytics

Interfejs Edge

  1. Otwórz Apigee Edge > Administracja > Środowiska > Serwery docelowe.
  2. Wybierz konkretny serwer docelowy określony przez serwer proxy interfejsu API i kliknij Edytuj.
  3. Sprawdź port podany dla serwera docelowego i informacje SSL.

  4. Jeśli serwer docelowy jest skonfigurowany z bezpiecznym portem (np. 443), ale protokół SSL nie jest włączony, to jest przyczyną tego problemu.

    Jak widać na zrzucie ekranu powyżej, używany port to 443, ale w konfiguracji serwera docelowego nie włączono SSL dla tego portu. Powoduje to, że procesor wiadomości w Apigee Edge wysyła żądania HTTP do bezpiecznego portu 443. Dlatego pojawia się błąd 400 Bad Request z komunikatem The plain HTTP request was sent to HTTPS port.

interfejs API zarządzania Google Analytics

  1. Uruchom interfejs API pobierania serwera docelowego, aby uzyskać szczegółowe informacje o konkretnej konfiguracji serwera docelowego, jak pokazano poniżej:

    Użytkownik chmury publicznej:

    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"

    Użytkownik 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. Sprawdź port podany dla serwera docelowego i informacje SSL.

  3. Jeśli serwer docelowy jest skonfigurowany z bezpiecznym portem (np. 443), ale sekcja SSLInfo nie jest zdefiniowana lub jest wyłączona, to jest przyczyną tego problemu.

    Przykładowa konfiguracja serwera docelowego:

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

    W przykładowych danych wyjściowych powyżej widać, że port używany na potrzeby połączenia docelowego to 443, ale nie ma bloku konfiguracji SSLInfo.

    Powoduje to, że procesor wiadomości w Apigee Edge wysyła żądania HTTP do bezpiecznego portu 443. Dlatego pojawia się błąd 400 Bad Request z komunikatem The plain HTTP request was sent to HTTPS port.

Rozdzielczość

Jeśli serwer docelowy jest bezpieczny lub ma skonfigurowany protokół TLS, musisz włączyć SSL dla konkretnego serwera docelowego.

W tym celu użyj jednej z następujących opcji:

  • Interfejs Edge
  • interfejs API zarządzania Google Analytics

Interfejs Edge

  1. Otwórz serwer docelowy w sekcji Interfejs użytkownika Edge > Administracja > Środowiska > Serwery docelowe.
  2. Wybierz konkretny serwer docelowy i kliknij Edytuj.
  3. Jeśli serwer docelowy jest bezpieczny i używa portu takiego jak 443, włącz SSL, zaznaczając pole wyboru obok opcji SSL.
  4. Skonfiguruj Truststore, Ciphery i protokoły. (Tylko wtedy, gdy jest wymagane)

interfejs API zarządzania Google Analytics

Skonfiguruj serwer docelowy za pomocą interfejsu API zarządzania zgodnie z opisem w dokumentacji aktualizowania konfiguracji serwera docelowego.

Musisz zebrać informacje diagnostyczne

Jeśli problem nie ustąpi mimo wykonania powyższych instrukcji, zbierz poniższe informacje diagnostyczne i skontaktuj się z zespołem pomocy Apigee Edge.

  1. Jeśli jesteś użytkownikiem chmury publicznej, podaj te informacje:
    • Nazwa organizacji
    • Nazwa środowiska
    • Nazwa serwera proxy interfejsu API
    • Wykonaj polecenie curl, aby odtworzyć błąd
    • Dane wyjściowe narzędzia do śledzenia (jeśli udało Ci się przechwycić nieudane żądanie)
  2. Jeśli jesteś użytkownikiem Private Cloud, podaj te informacje:
    • Zaobserwowano pełny komunikat o błędzie
    • Nazwa środowiska
    • Pakiet proxy interfejsu API
    • Definicja serwera docelowego (jeśli w punkcie końcowym używasz serwera docelowego)
    • Dane wyjściowe narzędzia do śledzenia (jeśli udało Ci się przechwycić nieudane żądanie)