400 Richiesta errata - Richiesta HTTP semplice inviata alla porta HTTPS

Stai visualizzando la documentazione di Apigee Edge.
Vai alla documentazione di Apigee X. informazioni

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 seguente pagina di errore 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>

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 cloud pubblico e privato perimetrale
Richiesta HTTP a un endpoint di destinazione configurato con TLS Richiesta HTTP effettuata a un server di backend abilitato per TLS nell'endpoint di destinazione. Utenti di cloud pubblico e privato perimetrale
Configurazione errata del server di destinazione Il server di destinazione è configurato con la porta protetta 443, ma SSL non è abilitato. Utenti di cloud pubblico e privato perimetrale

Causa: richiesta HTTP a un host virtuale configurato con TLS

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

Diagnostica

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

  1. Verifica la richiesta API e controlla se stai effettuando una richiesta HTTP per un alias host configurato per accettare richieste solo sulla porta sicura 443. Se sì, è 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 protetta 443. Questa è la causa dell'errore 400 Bad Request.

Risoluzione

Devi verificare se il client utilizza HTTP anziché HTTPS ed eseguire 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 a un endpoint di destinazione configurato con TLS

Questo errore si verifica se le richieste HTTP a un server di backend abilitato per TLS sono state configurate in modo errato nell'endpoint di destinazione di un proxy API.

Diagnostica

Per diagnosticare l'errore utilizzando lo strumento Trace, procedi nel seguente modo:

  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 non riuscite con il codice di risposta 400.
  4. Esplora le varie fasi e determina dove si è verificato l'errore.

  5. In genere, la risposta di errore 400 viene visualizzata dal server di backend. In altre parole, visualizzerai la risposta di errore 400 nella fase Risposta ricevuta dal server di destinazione, come mostrato di seguito:

  6. Determina l'endpoint di destinazione per il quale è stata effettuata la richiesta facendo clic sull'icona AX (Analytics Data Recorded) nella traccia.

  7. Prendi nota del file 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 di destinazione è 443, ma il protocollo è HTTP.
  8. Rivedi la definizione dell'endpoint di destinazione per comprendere la configurazione.

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

    Esempio di configurazione dell'endpoint di destinazione:

    <?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 riportato sopra mostra che stai utilizzando il protocollo HTTP, ma la porta usata è la porta protetta 443. In questo modo il server di backend risponde con 400 Bad Request e con il messaggio di errore The plain HTTP request was sent to HTTPS port.

Risoluzione

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

    Esempio di configurazione dell'endpoint di destinazione:

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

  2. Se il tuo server di backend è non sicuro:

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

    Esempio di configurazione dell'endpoint di destinazione:

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

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

Diagnostica

Per diagnosticare l'errore utilizzando lo strumento Trace, procedi nel seguente modo:

  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 non riuscite con il codice di risposta 400.
  4. Esplora le varie fasi e determina dove si è verificato l'errore.

  5. In genere, la 400 risposta di errore viene visualizzata dal server di backend. Vedrai la risposta di errore 400 nella fase Risposta ricevuta dal server di destinazione, come mostrato di seguito:

  6. Determina l'endpoint di destinazione per il quale è stata effettuata la richiesta facendo clic sull'icona AX (Analytics Data Recorded) nella traccia.

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

    Nel file di traccia di esempio precedente, target.name è default. Questo indica che l'endpoint di destinazione utilizzato per questa richiesta è predefinito.

  8. Rivedi la definizione dell'endpoint di destinazione per comprendere la configurazione.

    Esempio di configurazione dell'endpoint di destinazione:

    <?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 di esempio dell'endpoint di destinazione riportata sopra mostra che stai utilizzando un server di destinazione denominato faulty-target.

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

    • UI perimetrale
    • API di gestione

UI perimetrale

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

  4. Se il server di destinazione è configurato con una porta protetta (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 quella porta nella configurazione del server di destinazione. In questo modo il processore di messaggi di Apigee Edge invierà richieste HTTP alla porta sicura 443. Di conseguenza, ottieni l'errore 400 Bad Request con il messaggio The plain HTTP request was sent to HTTPS port.

API di gestione

  1. Esegui l'API Ottieni server di destinazione per ottenere i dettagli sulla configurazione specifica del server di destinazione come mostrato di seguito:

    Utente del cloud pubblico:

    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 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 di destinazione e le informazioni SSL.

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

    Esempio di configurazione del server di destinazione:

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

    Nell'output di esempio riportato sopra, vediamo che la porta utilizzata per la connessione di destinazione è 443, ma non è presente un blocco di configurazione SSLInfo.

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

Risoluzione

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

A tale scopo, utilizza una delle seguenti opzioni:

  • UI perimetrale
  • API di gestione

UI perimetrale

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

API di gestione

Utilizza l'API di gestione per configurare il server di destinazione come descritto nella documentazione relativa all' aggiornamento della configurazione del server di destinazione.

Devi raccogliere dati diagnostici

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

  1. Se sei un utente del cloud pubblico, fornisci le seguenti informazioni:
    • Nome dell'organizzazione.
    • Nome ambiente
    • Nome proxy API
    • Completa il comando curl per riprodurre l'errore
    • Output dello strumento Trace (se sei riuscito ad acquisire per la richiesta non riuscita)
  2. Se sei un utente Private Cloud, fornisci le seguenti informazioni:
    • Rilevato messaggio di errore completo
    • Nome ambiente
    • Bundle di proxy API
    • Definizione del server di destinazione (se utilizzi il server di destinazione nell'endpoint)
    • Output dello strumento Trace (se sei riuscito ad acquisire per la richiesta non riuscita)