Condividi tramite

Codici di risposta HTTP nel gateway delle applicazioni

Questo articolo illustra i motivi per cui il gateway applicazione di Azure restituisce codici di risposta HTTP specifici. Vengono descritte le cause comuni e le procedure di risoluzione dei problemi per determinare la causa radice del codice di risposta HTTP degli errori. I codici di risposta HTTP possono essere restituiti a una richiesta client indipendentemente dal fatto che sia stata avviata una connessione a una destinazione back-end.

Codici di risposta 3XX (reindirizzamento)

Le risposte HTTP comprese tra 300 e 399 vengono visualizzate quando una richiesta client corrisponde a una regola del gateway applicativo per cui sono configurati i reindirizzamenti. I reindirizzamenti possono essere configurati in una regola così come sono o tramite una regola della mappa del percorso. Per altre informazioni sui reindirizzamenti, vedere Panoramica sui reindirizzamenti di Application Gateway.

301 - Reindirizzamento permanente

Vengono visualizzate risposte HTTP 301 quando si specifica una regola di reindirizzamento con il valore Permanente.

302 - Trovato

Vengono visualizzate risposte HTTP 302 quando si specifica una regola di reindirizzamento con il valore Trovato.

303 - Vedi altri

Vengono visualizzate risposte HTTP 302 quando si specifica una regola di reindirizzamento con il valore Vedi altro.

307 - Reindirizzamento temporaneo

Vengono visualizzate risposte HTTP 307 quando si specifica una regola di reindirizzamento con il valore Temporaneo.

Codici di risposta 4XX (errore del client)

I codici di risposta 400-499 indicano un problema generato dal client. Questi problemi possono variare dal cliente che avvia richieste a un nome host non corrispondente, dal timeout della richiesta, dalla richiesta non autenticata, dalla richiesta dannosa e altro ancora.

Il gateway dell'applicazione raccoglie le metriche che mostrano la distribuzione dei codici di stato 4xx/5xx e dispone di un meccanismo di registrazione che acquisisce informazioni come l'indirizzo IP del client URI insieme al codice di risposta. Le metriche e la registrazione contribuiscono ulteriormente alla risoluzione dei problemi. I client possono anche ricevere una risposta 4xx da altri proxy tra il dispositivo client e l'Application Gateway. Ad esempio, rete CDN (rete per la distribuzione di contenuti) e altri provider di autenticazione. Vedi gli articoli seguenti per altre informazioni.

Metriche supportate dallo SKU di Application Gateway V2Log di diagnostica

400 - Richiesta non valida

I codici di risposta HTTP 400 vengono in genere restituiti quando:

  • Il traffico non HTTP/HTTPS viene avviato in un gateway applicativo con un listener HTTP o HTTPS.
  • Il traffico HTTP viene avviato in un listener con HTTPS, senza reindirizzamento configurato.
  • L'autenticazione reciproca è configurata e non è in grado di negoziare correttamente.
  • La richiesta non è conforme a RFC.

Alcuni motivi comuni per cui la richiesta non è conforme a RFC sono:

Categoria Esempi
Host non valido nella riga della richiesta L'host contiene due punti (example.com:8090:8080)
Intestazione host mancante La richiesta non include l'intestazione host
Presenza di caratteri non validi o non ammessi I caratteri riservati sono &,!.. Per ovviare alla limitazione, è possibile codificarli come percentuale. ad esempio %&
Versione HTTP non valida Richiedi /content.css HTTP/0.3
Caratteri non ASCII nel nome del campo di intestazione e nell'URI GET /«úü¡»*.doc HTTP/1.1
Intestazione Content-Length mancante per la richiesta POST Facilmente comprensibile
Metodo HTTP non valido GET123 /index.html HTTP/1.1
Intestazioni duplicate Authorization:<contenuto con codifica Base64 >, Authorization:<contenuto con codifica Base64>
Valore non valido per Content-Length Content-Length: abc,Content-Length: -10

Nei casi in cui è configurata l'autenticazione reciproca, diversi scenari possono causare la restituzione di una risposta HTTP 400 al client, ad esempio:

  • L'autenticazione reciproca è abilitata ma il certificato client non è stato presentato.
  • La convalida DN (Nome distinto) è abilitata e il DN del certificato client non corrisponde al DN della catena di certificati specificata.
  • La catena di certificati client non corrisponde a quella configurata nei criteri SSL definiti.
  • Il certificato client è scaduto.
  • Il controllo di revoca del client OCSP (Online Certificate Status Protocol) è abilitato e il certificato viene revocato.
  • Controllo di revoca del client OCSP (Online Certificate Status Protocol) abilitato, ma non può essere contattato.
  • Il controllo di revoca del client OCSP (Online Certificate Status Protocol) è abilitato, ma il risponditore OCSP non è fornito nel certificato.

Per altre informazioni sulla risoluzione dei problemi relativi all'autenticazione reciproca, vedere Risoluzione dei problemi relativi ai codici errore.

401 - Non autorizzato

Viene restituita una risposta HTTP 401 - Non autorizzato se il client non è autorizzato ad accedere alla risorsa. Sono diversi i motivi per cui viene restituita la risposta 401. Di seguito sono riportati alcuni motivi con le possibili correzioni.

  • Se il client ha accesso, potrebbe avere una cache del browser obsoleta. Svuotare la cache del browser e riprovare ad accedere all'applicazione.

È possibile che alla richiesta di probe AppGW venga restituita una risposta HTTP 401 - Non autorizzato se il pool back-end è configurato con l'autenticazione NTLM. In questo scenario, il back-end viene contrassegnato come integro. Esistono diversi modi per risolvere questo problema:

  • Consentire l'accesso anonimo nel backend pool.
  • Configurare il probe per inviare la richiesta a un altro sito "falso" che non richiede NTLM.
  • Non consigliato, perché questo non indica se il sito effettivo protetto dal gateway applicazione è attivo o meno.
  • Configurare il gateway applicazione per consentire risposte 401 come valide per i probe: Condizioni di corrispondenza dei probe.

403 - Accesso negato

La risposta HTTP 403 - Accesso negato viene visualizzata quando i clienti usano SKU WAF e WAF (Web application firewall) è configurato in modalità di prevenzione. Se i set di regole WAF abilitati o le regole WAF di rifiuto personalizzate corrispondono alle caratteristiche di una richiesta in ingresso, al client viene restituita una risposta 403 - Accesso negato.

Altri motivi per cui i client ricevono risposte 403 - Accesso negato:

  • Il Servizio app viene usato come back-end ed è configurato per consentire l'accesso solo dal gateway applicazione. Con questa configurazione i Servizi app possono restituire un errore 403. Questo si verifica in genere a causa di reindirizzamenti/collegamenti href che puntano direttamente ai Servizi app invece di puntare all'indirizzo IP del gateway applicazione.
  • Se accedi a un blog di archiviazione e l'endpoint di archiviazione e l'Application Gateway si trovano in aree diverse, viene restituito un errore 403 se l'indirizzo IP pubblico dell'Application Gateway non è incluso nell'elenco degli indirizzi consentiti. Vedere Concedere l'accesso da un intervallo IP Internet.

404 - Pagina non trovata

Una risposta HTTP 404 viene generata quando viene effettuata una richiesta al Gateway Applicazioni (SKU V2) con un nome host che non corrisponde a nessuno dei listener Multisito configurati e non è presente alcun listener Basic. Altre informazioni sui tipi di listener.

408 - Timeout della richiesta

È possibile che venga restituita una risposta HTTP 408 quando le richieste client al listener front-end del gateway di applicazione non ricevono risposta entro 60 secondi. Questo errore può essere causato dalla congestione del traffico tra reti locali e Azure, quando l'appliance virtuale controlla il traffico o il client stesso viene sovraccaricato.

413 - Entità della richiesta troppo grande

È possibile osservare una risposta HTTP 413 quando si utilizza il Web Application Firewall di Azure su Gateway Applicazione e le dimensioni della richiesta del client superano il limite massimo della dimensione del corpo della richiesta. Il campo dimensione massima del corpo della richiesta controlla il limite complessivo delle dimensioni della richiesta, escludendo qualsiasi caricamento di file. Il valore predefinito per le dimensioni del corpo della richiesta è 128 kB. Per altre informazioni, vedere Limiti relativi alle dimensioni delle richieste di Web application firewall.

499 - Il client ha chiuso la connessione

Viene visualizzata una risposta HTTP 499 se una richiesta client inviata ai gateway applicazione tramite SKU v2 viene chiusa prima che il server abbia terminato la risposta. Questo errore è osservabile in due scenari. Il primo scenario è quando viene restituita una risposta di grandi dimensioni al client e il client potrebbe aver chiuso o aggiornato l'applicazione prima che il server abbia completato l'invio di una tale risposta. Il secondo scenario è quando il timeout sul lato client è basso e non attende abbastanza a lungo per ricevere la risposta dal server. In questo caso è preferibile aumentare il timeout nel client. Nei gateway applicazione che usano lo SKU v1 potrebbe essere generato un codice di risposta HTTP 0 anche per il client che chiude la connessione prima che il server abbia terminato di rispondere.

Codici di risposta 5XX (errore del server)

I codici di risposta 500-599 indicano che si è verificato un problema relativo al gateway applicazione o al server back-end durante l'esecuzione della richiesta.

500 - Errore interno del server

Il gateway applicazione di Azure non deve presentare 500 codici di risposta. Aprire una richiesta di supporto se viene visualizzato questo codice, perché questo problema è un errore interno al servizio. Per informazioni su come aprire un caso di supporto, vedere Creare una richiesta di supporto tecnico di Azure.

502 - Gateway non valido

Gli errori HTTP 502 possono avere diverse cause radice, ad esempio:

Per informazioni sugli scenari in cui si verificano errori 502 e su come risolverli, vedere Risolvere gli errori di tipo Gateway non valido.

504 - Timeout del gateway

Lo SKU del gateway applicazione di Azure V2 invia errori HTTP 504 se il tempo di risposta del back-end supera il valore di timeout configurato nell'impostazione del back-end.

IIS (server Web Internet Information Services)

Se il server back-end è IIS, vedere Limiti predefiniti per siti Web per impostare il valore di timeout. Per informazioni dettagliate, vedere l'attributo connectionTimeout. Verificare che il timeout della connessione in IIS corrisponda o non superi il timeout impostato nell'impostazione back-end.

Nginx

Se il server back-end è Nginx o Nginx Ingress Controller e se dispone di server upstream, verificare che il valore di nginx:proxy_read_timeout corrisponda o non superi il timeout impostato nel parametro di configurazione del back-end.

Scenari di risoluzione dei problemi

Errore "ERRORINFO_INVALID_HEADER" nei log di accesso

Problema: il log di accesso visualizza un errore "ERRORINFO_INVALID_HEADER" per una richiesta, nonostante il codice di risposta back-end (serverStatus) sia 200. In altri casi, il server back-end potrebbe restituire 500.

Causa: il client invia un'intestazione contenente caratteri CR LF.

Soluzione: Sostituire i caratteri CR LF con uno spazio e inviare nuovamente la richiesta all'Application Gateway.

Passaggi successivi

Se le informazioni contenute in questo articolo non consentono di risolvere il problema, inviare un ticket di supporto.