Condividi tramite

Codici di risposta HTTP nel gateway applicazione

  • Articolo

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)

Vengono visualizzate risposte HTTP comprese tra 300 e 399 quando una richiesta client corrisponde a una regola del gateway applicazione 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 del reindirizzamento nel gateway applicazione.

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 sono di varia natura e possono riguardare, ad esempio, un client che esegue richieste a un nome host non corrispondente, il timeout di una richiesta, una richiesta non autenticata o una richiesta fraudolenta.

Il gateway applicazione raccoglie le metriche che acquisiscono la distribuzione dei codici di stato 4xx/5xx e ha un meccanismo di registrazione che acquisisce informazioni quali l'indirizzo IP del client URI con il 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 il gateway applicazione, ad esempio la rete CDN e altri provider di autenticazione. Vedi gli articoli seguenti per altre informazioni.

Metriche supportate dallo SKU del gateway applicazione 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 applicazione 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 codificare i caratteri aggiungendo il segno di percentuale, ad esempio %&
Versione HTTP non valida Get /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 in 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:

  • Il certificato client non viene presentato, ma l'autenticazione reciproca è abilitata.
  • La convalida DN è abilitata e il nome DN del certificato client non corrisponde a quello 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 è abilitato e il certificato viene revocato.
  • Il controllo di revoca del client OCSP è abilitato, ma è impossibile contattarlo.
  • Il controllo di revoca del client OCSP è abilitato, ma il risponditore OCSP non è indicato 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 pool back-end.
  • 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 è 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 si accede a un BLOB di archiviazione e l'endpoint di archiviazione e il gateway applicazione si trovano in un'area diversa, viene restituito un errore 403 se l'IP pubblico del gateway applicazione non è incluso nell'elenco degli indirizzi consentiti. Vedere Concedere l'accesso da un intervallo IP Internet.

404 - Pagina non trovata

È possibile che venga restituita una risposta HTTP 404 se si invia una richiesta a un gateway applicazione che:

408 - Timeout richiesta

È possibile che venga restituita una risposta HTTP 408 quando le richieste client al listener front-end del gateway applicazione non rispondono 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 che venga restituita una risposta HTTP 413 quando si usa Web application firewall di Azure nel gateway applicazione e le dimensioni della richiesta client superano il limite massimo delle dimensioni per il 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 l'intervallo di attesa non è sufficiente 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

Gateway applicazione di Azure non dovrebbe 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 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

Se il server back-end è IIS, consultare la sezione 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 è ngix o il controller in ingresso nginx e include server upstream, assicurarsi che il valore di nginx:proxy_read_timeout sia uguale o inferiore al timeout impostato nell'impostazione del back-end.

Passaggi successivi

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