400 Richiesta errata - Richiesta HTTP semplice inviata alla porta HTTPS

Stai visualizzando la documentazione di Apigee Edge.
Consulta la documentazione di Apigee X. info

Sintomo

L'applicazione client riceve una risposta HTTP 400 Bad Request con il messaggio The plain HTTP request was sent to HTTPS port.

Messaggio di errore

L'applicazione client riceve il seguente codice di risposta: 

HTTP/1.1 400 Bad Request

Seguito dalla pagina di errore HTML riportata di seguito: 

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

Possibili cause

Causa Descrizione Istruzioni per la risoluzione dei problemi applicabili a
Richiesta HTTP a un host virtuale configurato con TLS Il client invia una richiesta HTTP a un host virtuale configurato con TLS Utenti di Edge Public Cloud e Private Cloud
Richiesta HTTP all'endpoint target configurato con TLS Richiesta HTTP effettuata a un server di backend abilitato per TLS nell'endpoint target. Utenti di Edge Public Cloud e Private Cloud
Configurazione errata del server target Il server target è configurato con la porta sicura 443, ma SSL non è abilitato. Utenti di Edge Public Cloud e Private Cloud

Causa: richiesta HTTP a un host virtuale configurato con TLS

Questo errore si verifica quando un client tenta di connettersi a un'API su Apigee e l'host virtuale menzionato è configurato per utilizzare SSL e riceve invece una richiesta HTTP.

Diagnosi

Poiché questo problema si verifica sull'endpoint Northbound e le richieste API non vanno a buon fine nel punto di interazione tra l' applicazione client e il router, questi messaggi di errore non vengono registrati nei log di accesso del router NGINX. Di conseguenza, queste richieste non verranno acquisite in strumenti come il monitoraggio API e lo strumento Trace.

  1. Verifica la richiesta API e controlla se stai effettuando una richiesta HTTP per un alias host che è configurato per accettare richieste solo sulla porta sicura 443. In caso affermativo, questa è la causa del problema.

    Esempio di richiesta API errata:

    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. Nella richiesta di esempio riportata sopra, tieni presente che viene effettuata una richiesta HTTP all'alias host myorg-test.apigee.net sulla porta sicura 443. Questa è la causa dell' 400 Bad Request errore.

Risoluzione

Devi verificare se il client utilizza HTTP anziché HTTPS ed effettuare la richiesta corretta come mostrato di seguito:

Esempio di richiesta API:

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

o

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

Causa: richiesta HTTP all'endpoint target configurato con TLS

Questo errore si verifica se hai configurato in modo errato le richieste HTTP a un server di backend abilitato per TLS nell'endpoint target di un proxy API.

Diagnosi

Per diagnosticare l'errore utilizzando lo strumento Trace:

  1. Abilita Trace nell'interfaccia utente di Apigee per il proxy API interessato.
  2. Effettua richieste al proxy API.
  3. Seleziona una delle richieste API che non è andata a buon fine con il codice di risposta 400.
  4. Esamina le varie fasi e determina dove si è verificato l'errore.

  5. In genere, la risposta di errore 400 proviene dal server di backend. Ovvero, vedrai la risposta di errore 400 nella fase Risposta ricevuta dal server target come mostrato di seguito:

  6. Determina l'endpoint target per il quale è stata effettuata la richiesta facendo clic sull'icona AX (Dati di analisi registrati) nella traccia.

  7. Prendi nota di target.url, che contiene il protocollo, l'alias host del server di backend, e, a volte, il numero di porta. La porta utilizzata per l' URL target è 443 ma il protocollo è HTTP.
  8. Esamina la definizione dell'endpoint target per comprendere la configurazione.

  9. Verifica che l'host del server di backend sia sicuro e che sia in ascolto su una porta sicura come 443. Se utilizzi il protocollo come http nell'elemento <URL>, questa è la causa del problema.

    Esempio di configurazione dell'endpoint target:

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

    L'esempio precedente mostra che stai utilizzando il protocollo HTTP, ma la porta utilizzata è la porta sicura porta 443. In questo modo, il server di backend risponde con 400 Bad Request e il messaggio di errore The plain HTTP request was sent to HTTPS port.

Risoluzione

  1. Se il server di backend è sicuro/abilitato per TLS, assicurati di utilizzare il protocollo come https nell'elemento <URL> dell'endpoint target, come mostrato in nell'esempio seguente:

    Esempio di configurazione dell'endpoint target:

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

  2. Se il server di backend non è sicuro:

    • Non menzionare il numero di porta sicura, ad esempio 443.
    • Non devi menzionare il numero di porta, se il server di backend è in ascolto su una porta non sicura standard
    • Menziona il numero di porta se utilizzi un'altra porta non sicura, ad esempio: 9080

    Esempio di configurazione dell'endpoint target:

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

or

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

Causa: configurazione errata del server target

Se il server target è configurato con una porta sicura come 443 senza abilitare SSL, il processore di messaggi di Apigee Edge invia richieste HTTP a un server target sicuro o configurato con TLS, causando questo problema.

Diagnosi

Per diagnosticare l'errore utilizzando lo strumento Trace:

  1. Abilita Trace nell'interfaccia utente di Apigee per il proxy API interessato.
  2. Effettua richieste al proxy API.
  3. Seleziona una delle richieste API che non è andata a buon fine con il codice di risposta 400.
  4. Esamina le varie fasi e determina dove si è verificato l'errore.

  5. In genere, la risposta di errore 400 proviene dal server di backend. Ovvero, vedrai la risposta di errore 400 nella fase Risposta ricevuta dal server target come mostrato di seguito:

  6. Determina l'endpoint target per il quale è stata effettuata la richiesta facendo clic sull'icona AX (Dati di analisi registrati) nella traccia.

  7. Prendi nota di target.name, che rappresenta il nome dell'endpoint target.

    Nel file di traccia di esempio riportato sopra, target.name è default. Ciò indica che l'endpoint target utilizzato per questa richiesta è quello predefinito.

  8. Esamina la definizione dell'endpoint target per comprendere la configurazione.

    Esempio di configurazione dell'endpoint target:

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

    La configurazione dell'endpoint target di esempio riportata sopra mostra che stai utilizzando un server target denominato faulty-target.

  9. Una volta ottenuto il nome del server target, puoi utilizzare uno dei seguenti metodi per controllare la configurazione del server target:

    • Interfaccia utente di Edge
    • API di gestione

Interfaccia utente di Edge

  1. Vai a Apigee Edge > Amministratore > Ambienti > Server target.
  2. Scegli il server target specifico identificato dal proxy API e fai clic su Modifica.
  3. Verifica la porta specificata per il server target e le informazioni SSL.

  4. Se il server target è configurato con una porta sicura (ad esempio 443), ma SSL non è abilitato, questa è la causa del problema.

    Come puoi vedere nello screenshot riportato sopra, la porta utilizzata è 443 ma SSL non è abilitato per questa porta nella configurazione del server target. In questo modo, il processore di messaggi di Apigee Edge invia richieste HTTP alla porta sicura 443. Di conseguenza, ricevi l' errore 400 Bad Request con il messaggio The plain HTTP request was sent to HTTPS port.

API di gestione

  1. Esegui l'API Get target server per ottenere i dettagli sulla configurazione del server target specifico come mostrato di seguito:

    Utente di 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"

    Utente di 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. Verifica la porta specificata per il server target e le informazioni SSL.

  3. Se il server target è configurato con una porta sicura (ad esempio 443), ma la sezione SSLInfo non è definita o non è abilitata, questa è la causa del problema.

    Esempio di configurazione del server target:

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

    Nell'output di esempio riportato sopra, possiamo vedere che la porta utilizzata per la connessione target è 443, ma non è presente alcun blocco di configurazione SSLInfo.

    In questo modo, il processore di messaggi di Apigee Edge invia richieste HTTP alla porta sicura 443. Di conseguenza, ricevi l'errore 400 Bad Request con il messaggio The plain HTTP request was sent to HTTPS port.

Risoluzione

Se il server target è sicuro o configurato con TLS, devi abilitare SSL per il target server specifico.

Puoi farlo utilizzando una delle seguenti opzioni:

  • Interfaccia utente di Edge
  • API di gestione

Interfaccia utente di Edge

  1. Vai al server target nell'interfaccia utente di Edge > Amministratore > Ambienti > Server target.
  2. Scegli il server target specifico e fai clic su Modifica.
  3. Se il server target è sicuro e utilizza una porta come 443, abilita SSL selezionando la casella di controllo accanto all'opzione SSL.
  4. Configura Truststore, Cifratura e Protocolli. (Solo se necessario)

API di gestione

Utilizza l'API di gestione per configurare il server target come descritto nella Aggiornare la configurazione del server target documentazione.

Informazioni di diagnostica da raccogliere

Se il problema persiste anche dopo aver seguito le istruzioni riportate sopra, raccogli le seguenti informazioni di diagnostica e contatta l'assistenza Apigee Edge.

  1. Se sei un utente di Public Cloud, fornisci le seguenti informazioni:
    • Nome organizzazione
    • Nome ambiente
    • Nome del proxy API
    • Comando curl completo per riprodurre l'errore
    • Output dello strumento Trace (se sei riuscito ad acquisire la richiesta non riuscita)
  2. Se sei un utente di Private Cloud, fornisci le seguenti informazioni:
    • Messaggio di errore completo osservato
    • Nome ambiente
    • Bundle del proxy API
    • Definizione del server target (se utilizzi il server target nell'endpoint)
    • Output dello strumento Trace (se sei riuscito ad acquisire la richiesta non riuscita)