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

Przeglądasz dokumentację Apigee Edge.
Przejdź do Dokumentacja 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 otrzymuje ten kod odpowiedzi: 

HTTP/1.1 400 Bad Request

A następnie 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 przez TLS Klient wysyła żądanie HTTP do hosta wirtualnego skonfigurowanego przez TLS Użytkownicy chmury publicznej i prywatnej Edge
Żądanie HTTP do docelowego punktu końcowego skonfigurowanego przez TLS Żądanie HTTP wysłane do serwera backendu z włączonym protokołem TLS w docelowym 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 przez TLS

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

Diagnostyka

Ten problem występuje w W kierunku północnym punkt końcowy i żądania API kończą się niepowodzeniem na interakcji z punktem wejścia między aplikacji klienckiej i routera, te komunikaty o błędach nie są rejestrowane w routerze NGINX dzienników dostępu. W związku z tym żądania te nie będą rejestrowane w narzędziach takich jak API Monitoring czy w narzędziu śledzenia.

  1. Potwierdź żądanie do interfejsu API i sprawdź, czy wysyłasz żądanie HTTP dla aliasu hosta, skonfigurowano do akceptowania żądań tylko na bezpiecznym porcie 443. Jeśli tak, i to jest przyczyna problemu.

    Przykład nieprawidłowego żądania 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 jest wysyłane do aliasu hosta myorg-test.apigee.net na bezpiecznym porcie 443. To jest przyczyna 400 Bad Request błąd.

Rozdzielczość

Sprawdź, czy klient używa protokołu HTTP, a nie HTTP, i wyślij prawidłowe żądanie: 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 przez TLS

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

Diagnostyka

Aby zdiagnozować błąd za pomocą narzędzia śledzenia, wykonaj te czynności:

  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 kodem odpowiedzi 400.
  4. Przejdź przez różne fazy i określ, gdzie wystąpił błąd.

  5. Zwykle odpowiedź o błędzie 400 pochodzi z serwera backendu. Oznacza to, że w fazie Otrzymanie odpowiedzi pojawi się błąd 400 z serwera docelowego, jak poniżej:

  6. Aby określić docelowy punkt końcowy, do którego przesłano żądanie, kliknij AX. (Analytics Data Recorded) w śladzie.

  7. Zapisz parametr target.url, który zawiera protokół, alias hosta serwera backendu a czasem też numer portu. Port używany do docelowy adres URL to 443, ale protokół to HTTP.
  8. Aby zrozumieć konfigurację, sprawdź definicję docelowego punktu końcowego.

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

    Przykład powyżej pokazuje, że używasz protokołu HTTP, ale używany port jest bezpieczny. port 443. Dzięki temu serwer backendu w odpowiedzi przesyła 400 Bad Request i komunikat o błędzie The plain HTTP request was sent to HTTPS port

Rozdzielczość

  1. Jeśli Twój serwer backendu jest zabezpieczony/włączony TLS, sprawdź, czy używasz protokołu https w elemencie <URL> docelowego punktu końcowego, jak pokazano na następujący przykład:

    Przykładowa konfiguracja docelowego punktu końcowego:

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

  2. Jeśli serwer backendu jest niezabezpieczony:

    • Nie wspominaj o numerze bezpiecznego portu, np. 443.
    • Nie musisz wcale podawać numeru portu, jeśli serwer backendu nasłuchuje standardowy, niebezpieczny port
    • Podaj numer portu, jeśli korzystasz z 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 bezpiecznym portem, takim jak 443, bez włączania SSL, to sprawia, że procesor komunikatów Apigee Edge wysyła żądania HTTP do bezpiecznego lub Serwer docelowy skonfigurowany jako TLS, który prowadzi do tego problemu.

Diagnostyka

Aby zdiagnozować błąd za pomocą narzędzia śledzenia, wykonaj te czynności:

  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 kodem odpowiedzi 400.
  4. Przejdź przez różne fazy i określ, gdzie wystąpił błąd.

  5. Zwykle zwracana jest odpowiedź o błędzie 400 z serwera backendu. Oznacza to, że na etapie Otrzymanie odpowiedzi pojawi się błąd 400 z serwera docelowego, jak poniżej:

  6. Aby określić docelowy punkt końcowy, do którego przesłano żądanie, kliknij AX. (Analytics Data Recorded) w śladzie.

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

    W powyższym przykładowym pliku śledzenia parametr target.name to default. Oznacza to, że docelowy punkt końcowy używany w tym żądaniu jest domyślny.

  8. Aby zrozumieć konfigurację, sprawdź definicję docelowego punktu końcowego.

    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 określeniu nazwy serwera docelowego możesz użyć jednej z poniższych metod, aby: Sprawdź konfigurację serwera docelowego:

    • Interfejs Edge
    • interfejs API zarządzania Google Analytics

Interfejs Edge

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

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

    Jak widać na zrzucie ekranu powyżej, używany port to 443, ale protokół SSL nie jest włączone dla tego portu w konfiguracji serwera docelowego. Spowoduje to wyświetlenie komunikatu Apigee Edge Procesor wysyłający żądania HTTP do bezpiecznego portu 443. W związku z tym uzyskasz błąd 400 Bad Request z komunikatem The plain HTTP request was sent to HTTPS port.

interfejs API zarządzania Google Analytics

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

    Użytkownik Public Cloud:

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

  3. Jeśli serwer docelowy jest skonfigurowany z bezpiecznym portem (na przykład: 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 powyższych przykładowych danych wyjściowych widać, że port połączenia docelowego to 443, ale nie ma bloku konfiguracji SSLInfo.

    Spowoduje to, że procesor wiadomości Apigee Edge będzie 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 Twój serwer docelowy jest zabezpieczony lub skonfigurowany pod kątem TLS, musisz włączyć SSL dla określonego serwera serwera docelowego.

Aby to zrobić, użyj jednej z tych opcji:

  • Interfejs Edge
  • interfejs API zarządzania Google Analytics

Interfejs Edge

  1. Przejdź do serwera docelowego w interfejsie brzegowym 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 w zaznacz pole wyboru obok opcji SSL.
  4. Skonfiguruj Truststore, Ciphers i Protokoły. (tylko jeśli wymagane)

interfejs API zarządzania Google Analytics

Skonfiguruj serwer docelowy przy użyciu interfejsu API zarządzania zgodnie z opisem w Zaktualizuj dokumentację konfiguracji serwera docelowego.

Musi zbierać informacje diagnostyczne

Jeśli po wykonaniu powyższych czynności problem nie ustąpi, zwróć uwagę na informacje diagnostyczne, a następnie skontaktuj się z zespołem pomocy Apigee Edge.

  1. Jeśli jesteś użytkownikiem Public Cloud, 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ć dane dla nieudanego żądania)
  2. Jeśli jesteś użytkownikiem Private Cloud, podaj te informacje:
    • Zaobserwowano pełny komunikat o błędzie
    • Nazwa środowiska
    • Pakiet serwerów 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ć dane dla nieudanego żądania)