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

Wyświetlasz dokumentację Apigee Edge.
Otwórz dokumentację Apigee X. info

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 otrzymuje ten kod odpowiedzi: 

HTTP/1.1 400 Bad Request

A następnie tę stronę 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, których dotyczy
Żądanie HTTP do hosta wirtualnego skonfigurowanego pod kątem TLS Klient wysyła żądanie HTTP do hosta wirtualnego skonfigurowanego pod kątem TLS. Użytkownicy chmury publicznej i prywatnej Edge
Żądanie HTTP do punktu końcowego skonfigurowanego pod kątem TLS Żądanie HTTP wysłane do serwera backendu z włączonym TLS w punkcie końcowym. Użytkownicy chmury publicznej i prywatnej Edge
Nieprawidłowa konfiguracja serwera docelowego Serwer docelowy jest skonfigurowany z bezpiecznym portem 443, ale SSL nie jest włączony. Użytkownicy chmury publicznej i prywatnej Edge

Przyczyna: żądanie HTTP do hosta wirtualnego skonfigurowanego pod kątem 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 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 punkcie wejścia interakcji między aplikacją kliencką a routerem, te komunikaty o błędach nie są rejestrowane w dziennikach dostępu do routera NGINX. Dlatego te żądania nie będą rejestrowane w narzędziach takich jak monitorowanie interfejsu API i narzędzie do śledzenia.

  1. Sprawdź żądanie do interfejsu API i zobacz, czy wysyłasz żądanie HTTP do aliasu hosta, który jest skonfigurowany tak, aby akceptować żądania tylko na bezpiecznym porcie 443. Jeśli tak, to jest to przyczyna 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 powyższym przykładowym żądaniu zwróć uwagę, że żądanie HTTP jest wysyłane do aliasu hosta myorg-test.apigee.net na bezpiecznym porcie 443. Jest to przyczyna błędu 400 Bad Request.

Rozwiązanie

Musisz sprawdzić, czy klient używa protokołu HTTP zamiast HTTPS, i wysłać 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 punktu końcowego skonfigurowanego pod kątem TLS

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

Diagnostyka

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

  1. Włącz śledzenie w interfejsie Apigee dla proxy interfejsu API, którego dotyczy problem.
  2. Wysyłaj żądania do proxy interfejsu API.
  3. Wybierz jedno z żądań do interfejsu API, które zakończyło się niepowodzeniem z kodem odpowiedzi 400.
  4. Przejdź przez różne etapy i określ, gdzie wystąpił błąd.

  5. Zwykle zobaczysz odpowiedź o błędzie 400 pochodzącą z serwera backendu. Oznacza to, że odpowiedź o błędzie 400 zobaczysz na etapie Response received from target server (Odpowiedź otrzymana z serwera docelowego), jak pokazano poniżej:

  6. Aby określić punkt końcowy, do którego wysłano żądanie, kliknij ikonę AX (Zarejestrowane dane analityczne) w śladzie.

  7. Zanotuj target.url, który zawiera protokół, alias hosta serwera backendu, a czasami numer portu. Port używany w przypadku docelowego adresu URL to 443, ale protokół to HTTP.
  8. Aby zrozumieć konfigurację, zapoznaj się z definicją punktu końcowego.

  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 http, jest to przyczyna tego problemu.

    Przykładowa konfiguracja 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żywany port to bezpieczny port 443. Powoduje to, że serwer backendu odpowiada komunikatem 400 Bad Request i komunikatem o błędzie The plain HTTP request was sent to HTTPS port.

Rozwiązanie

  1. Jeśli serwer backendu jest bezpieczny lub ma włączony TLS, upewnij się, że w elemencie <URL> punktu końcowego używasz protokołu jako https, jak pokazano w tym przykładzie:

    Przykładowa konfiguracja punktu końcowego:

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

  2. Jeśli serwer backendu jest niezabezpieczony:

    • Nie podawaj bezpiecznego numeru portu, takiego jak 443.
    • Jeśli serwer backendu nasłuchuje na standardowym niezabezpieczonym porcie, nie musisz w ogóle podawać numeru portu.
    • Jeśli używasz innego niezabezpieczonego portu, np. 9080, podaj jego numer.

    Przykładowa konfiguracja 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 bezpiecznym portem, takim jak 443, bez włączonego protokołu SSL, powoduje to, że procesor komunikatów 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 śledzenie w interfejsie Apigee dla proxy interfejsu API, którego dotyczy problem.
  2. Wysyłaj żądania do proxy interfejsu API.
  3. Wybierz jedno z żądań do interfejsu API, które zakończyło się niepowodzeniem z kodem odpowiedzi 400.
  4. Przejdź przez różne etapy i określ, gdzie wystąpił błąd.

  5. Zwykle zobaczysz odpowiedź o błędzie 400 pochodzącą z serwera backendu. Oznacza to, że odpowiedź o błędzie 400 zobaczysz na etapie Response received from target server (Odpowiedź otrzymana z serwera docelowego), jak pokazano poniżej:

  6. Aby określić punkt końcowy, do którego wysłano żądanie, kliknij ikonę AX (Zarejestrowane dane analityczne) w śladzie.

  7. Zanotuj target.name, który reprezentuje nazwę punktu końcowego.

    W powyższym przykładowym pliku śledzenia target.name to default. Wskazuje to, że punktem końcowym używanym w tym żądaniu jest domyślny.

  8. Aby zrozumieć konfigurację, zapoznaj się z definicją punktu końcowego.

    Przykładowa konfiguracja 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 punktu końcowego pokazuje, że używasz serwera docelowego o nazwie faulty-target.

  9. Gdy masz już nazwę serwera docelowego, możesz użyć jednej z tych metod, aby sprawdzić jego konfigurację:

    • Interfejs Edge
    • Interfejs API zarządzania Google Analytics

Interfejs Edge

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

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

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

Interfejs API zarządzania Google Analytics

  1. Aby uzyskać szczegółowe informacje o konfiguracji konkretnego serwera docelowego, wykonaj wywołanie interfejsu API Get target server, 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 chmury prywatnej:

    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 określony dla serwera docelowego i informacje o SSL.

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

    Przykładowa konfiguracja serwera docelowego:

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

    W powyższym przykładowym wyniku widać, że port używany do połączenia docelowego to 443, ale nie ma SSLInfo bloku konfiguracji.

    Powoduje to, że procesor komunikatów Apigee Edge wysyła żądania HTTP na bezpieczny port 443. Dlatego otrzymujesz błąd 400 Bad Request z komunikatem The plain HTTP request was sent to HTTPS port.

Rozwiązanie

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

Możesz to zrobić, korzystając z jednej z tych opcji:

  • Interfejs Edge
  • Interfejs API zarządzania Google Analytics

Interfejs Edge

  1. Otwórz serwer docelowy w interfejsie 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 magazyn zaufanych certyfikatów, szyfry i protokoły. (Tylko w razie potrzeby)

Interfejs API zarządzania Google Analytics

Aby skonfigurować serwer docelowy za pomocą interfejsu API zarządzania, postępuj zgodnie z instrukcjami w dokumentacji Aktualizowanie konfiguracji serwera docelowego.

Informacje diagnostyczne, które musisz zebrać

Jeśli problem nadal występuje po wykonaniu powyższych instrukcji, zbierz te 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 proxy interfejsu API
    • Pełne polecenie curl do odtworzenia błędu
    • Dane wyjściowe narzędzia do śledzenia (jeśli udało Ci się je zarejestrować w przypadku żądania, które zakończyło się niepowodzeniem)
  2. Jeśli jesteś użytkownikiem chmury prywatnej, podaj te informacje:
    • Pełny komunikat o błędzie
    • Nazwa środowiska
    • Pakiet proxy interfejsu API
    • Definicja serwera docelowego (jeśli używasz serwera docelowego w punkcie końcowym)
    • Dane wyjściowe narzędzia do śledzenia (jeśli udało Ci się je zarejestrować w przypadku żądania, które zakończyło się niepowodzeniem)