400 Richiesta errata - Richiesta HTTP semplice inviata alla porta HTTPS

Stai visualizzando la documentazione di Apigee Edge.
Vai alla sezione 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

Seguita 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 Le istruzioni di 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 perimetrali di cloud pubblici e privati
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 perimetrali di cloud pubblici e privati
Configurazione del server di destinazione non corretta Il server di destinazione è configurato con la porta protetta 443, ma SSL non è abilitato. Utenti perimetrali di cloud pubblici e privati

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 è configurato per utilizzare SSL e riceve invece una richiesta HTTP.

Diagnosi

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

  1. Verifica la tua richiesta API e controlla se stai effettuando una richiesta HTTP per un alias host che è configurata per accettare richieste solo sulla porta sicura 443. Se sì, allora 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 fatta una richiesta HTTP all'alias host myorg-test.apigee.net sulla porta sicura 443. Questa è la causa 400 Bad Request errore.

Risoluzione

Devi verificare se il client utilizza HTTP anziché HTTPS ed effettuare la richiesta corretta come 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 hai configurato in modo errato le richieste HTTP per un backend abilitato per TLS server nell'endpoint di destinazione di un proxy API.

Diagnosi

Per diagnosticare l'errore utilizzando lo strumento Trace:

  1. Abilita Trace nella UI di Apigee per il proxy API interessato.
  2. Effettuare richieste al proxy API.
  3. Seleziona una delle richieste API non riuscite con il codice di risposta 400.
  4. Naviga attraverso le varie fasi e determina dove si è verificato l'errore.

  5. In genere viene visualizzata la risposta di errore 400 proveniente dal server di backend. In altre parole, verrà visualizzata 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) (Dati registrati di Analytics) nella traccia.

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

  9. Verifica che l'host del server di backend sia protetto e sia in ascolto su una porta protetta, come 443. Se utilizzi il protocollo come http nell'elemento <URL>: 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 precedente mostra che stai utilizzando il protocollo HTTP, ma la porta utilizzata è sicura porta 443. Questo fa sì che il server di backend risponda con 400 Bad Request e il messaggio di errore The plain HTTP request was sent to HTTPS port.

Risoluzione

  1. Se il tuo server di backend è abilitato per TLS/TLS, assicurati di utilizzare il protocollo come https nell'elemento <URL> dell'endpoint di destinazione, come mostrato in 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.
    • Se il server di backend è in ascolto, non devi menzionare il numero di porta una porta non sicura standard
    • Indica il numero di porta se utilizzi altre porte non sicure, 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 del server di destinazione errata

Se il server di destinazione è configurato con una porta sicura come 443 senza abilitare SSL, fa sì che il processore di messaggi di Apigee Edge invii richieste HTTP a un indirizzo Server di destinazione configurato con TLS che causa questo problema.

Diagnosi

Per diagnosticare l'errore utilizzando lo strumento Trace:

  1. Abilita Trace nella UI di Apigee per il proxy API interessato.
  2. Effettuare richieste al proxy API.
  3. Seleziona una delle richieste API non riuscite con il codice di risposta 400.
  4. Naviga attraverso le varie fasi e determina dove si è verificato l'errore.

  5. In genere viene visualizzata la 400 risposta di errore proveniente dal server di backend. Ciò significa che 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) (Dati registrati di Analytics) nella traccia.

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

    Nel file di traccia dell'esempio precedente, target.name è default. Ciò indica che l'endpoint di destinazione usato per questa richiesta sia predefinito.

  8. Esamina 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>

    L'esempio di configurazione dell'endpoint di destinazione riportato 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 Controlla la configurazione del server di destinazione:

    • UI Edge
    • API di gestione

UI Edge

  1. Vai a Apigee Edge > Amministratore > Ambienti > Server di destinazione.
  2. Scegli lo specifico server di destinazione 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 sicura (ad esempio: 443), ma SSL non è abilitato, ecco 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. Questo fa sì che il messaggio di Apigee Edge Processore per inviare richieste HTTP alla porta sicura 443. Di conseguenza, ottieni errore 400 Bad Request con il messaggio The plain HTTP request was sent to HTTPS port.

API di gestione

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

    Utente 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 sicura (ad esempio: 443), ma la sezione SSLInfo non è definita o non è abilitata, questo è il motivo questo problema.

    Esempio di configurazione del server di destinazione:

    {
  "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 di destinazione è 443, ma non è presente alcun blocco di configurazione SSLInfo.

    Questo fa sì che il processore di messaggi di Apigee Edge invii richieste HTTP alla porta sicura 443. Di conseguenza, con il messaggio viene visualizzato l'errore 400 Bad Request The plain HTTP request was sent to HTTPS port.

Risoluzione

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

Puoi farlo utilizzando una delle seguenti opzioni:

  • UI Edge
  • API di gestione

UI Edge

  1. Vai al server di destinazione in Edge UI > 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, attiva SSL selezionando la casella di controllo accanto all'opzione SSL.
  4. Configura Truststore, Cipher e Protocols. (Solo se richiesto)

API di gestione

Utilizzare l'API di gestione per configurare il server di destinazione come descritto in Aggiorna la documentazione sulla configurazione del server di destinazione.

Raccogliere dati diagnostici

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

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