Condividi tramite

Risoluzione degli errori HTTP 400 in IIS

Si applica a: Internet Information Services

Questo articolo descrive i passaggi per la risoluzione dei problemi per identificare la causa di vari errori HTTP 400 quando si usa IIS.

Panoramica

Dopo che un client HTTP(ad esempio Microsoft Edge) invia una richiesta HTTP a un server IIS, potrebbe visualizzare il tipo di messaggio di errore seguente:

HTTP 400 - Richiesta non valida

In questo scenario IIS rifiuta la richiesta HTTP del client perché la richiesta non soddisfa le regole di analisi HTTP del server, supera i limiti di tempo o non riesce altre regole a cui IIS o HTTP.sys richiede che le richieste in ingresso siano conformi. IIS invia di nuovo lo HTTP 400 - Bad Request stato al client e quindi termina la connessione TCP.

Strumenti

Metodi di risoluzione dei problemi

Quando si risolve una condizione HTTP 400, è importante ricordare che il problema sottostante è che il client ha inviato una richiesta a IIS che interrompe una o più regole che HTTP.sys applicano. Tenendo presente questo aspetto, è opportuno vedere esattamente cosa sta inviando il client a IIS. A tale scopo, acquisire una traccia di rete del client che invia la richiesta non valida. È possibile analizzare la traccia per visualizzare i dati non elaborati inviati dal client a IIS e visualizzare i dati di risposta non elaborati inviati da IIS al client. È anche possibile usare uno strumento di sniffer HTTP denominato Fiddler, un ottimo strumento in quanto consente di visualizzare le intestazioni HTTP anche se il client e il server comunicano tramite SSL.

L'elemento dati successivo usato è il file C:\Windows\System32\LogFiles\HTTPERR\httperr.log . In IIS, il componente HTTP.sys gestisce le richieste HTTP in ingresso prima che vengano passate a IIS ed è responsabile del blocco delle richieste che non soddisfano i requisiti iis. Quando HTTP.sys blocca la richiesta, registra le informazioni al file httperr.log relativo alla richiesta non valida e al motivo per cui è stato bloccato.

Note

Per altre informazioni sulla registrazione degli errori dell'API HTTP fornita da HTTP.sys, vedere Registrazione degli errori nell'API HTTP.

È tecnicamente possibile, anche se non molto probabile, che un client possa ricevere una risposta HTTP 400, che non ha una voce di log associata nel file httperr.log . Può verificarsi se un filtro ISAPI o un'estensione o un modulo HTTP in IIS imposta lo stato 400, nel qual caso è possibile esaminare il log IIS per altre informazioni. Può verificarsi anche se un'entità tra il client e il server, ad esempio un server proxy o un altro dispositivo di rete, intercetta una risposta da IIS ed esegue l'override con il proprio stato 400 e/o errore "Richiesta non valida".

Note

Questo articolo illustra principalmente gli errori HTTP 400 comuni prima di raggiungere il sito Web. In alcuni scenari, il sito Web potrebbe restituire anche errori HTTP 400 ai client a causa della logica del codice o del runtime personalizzato (ad esempio ASP.NET). Se non è ancora possibile risolvere gli errori HTTP 400 dopo aver eseguito i passaggi nelle sezioni seguenti, provare a risolvere i problemi usando la funzionalità Traccia richieste non riuscite in IIS. Se si rileva che gli errori HTTP 400 sono effettivamente impostati dal gestore di runtime corrispondente del sito Web, ad esempio ASP.NET, potrebbe essere necessario esaminare i dettagli delle richieste e delle risposte, insieme alla relativa logica di codice e alla configurazione del runtime del sito Web, per comprendere la causa degli errori HTTP 400.

Scenario di esempio

Di seguito è riportato un esempio di scenario HTTP 400, in cui un client invia una richiesta non valida a IIS e il server invia un messaggio "HTTP 400 - Richiesta non valida".

Quando il client invia la richiesta, l'errore del browser restituito è simile al seguente:

Richiesta non valida (campo intestazione troppo lungo)

L'acquisizione di una traccia di rete della richiesta e della risposta visualizza gli output seguenti:

RICHIESTA:

HTTP: GET Request from Client
HTTP: Request Method =GET
HTTP: Uniform Resource Identifier =/1234567890123456789012345678901234567890/time.asp
HTTP: Protocol Version =HTTP/1.1
HTTP: Accept-Language =en-us
HTTP: UA-cpu =x86
HTTP: Accept-Encoding =gzip, deflate
HTTP: Host =iisserver
HTTP: Connection =Keep-Alive
HTTP: Data: Number of data bytes remaining = 14 (0x000E)

RISPOSTA:

HTTP: Response to Client; HTTP/1.1; Status Code = 400 - Bad Request
HTTP: Protocol Version =HTTP/1.1
HTTP: Status Code = Bad Request
HTTP: Reason =Bad Request
HTTP: Content-Type =text/html
HTTP: Date =Wed, 14 Nov 2012 20:36:36 GMT
HTTP: Connection =close
HTTP: Content-Length =44
HTTP: Data: Number of data bytes remaining = 63 (0x003F)

Si noti che le intestazioni di risposta non indicano quanto il messaggio di errore nel browser. Tuttavia, se si esaminano i dati non elaborati nel corpo della risposta, vengono visualizzati altri elementi:

00000030                                           48 54               HT
00000040 54 50 2F 31 2E 31 20 34 30 30 20 42 61 64 20 52 TP/1.1.400.Bad.R
00000050 65 71 75 65 73 74 0D 0A 43 6F 6E 74 65 6E 74 2D equest..Content-
00000060 54 79 70 65 3A 20 74 65 78 74 2F 68 74 6D 6C 0D Type:.text/html.
00000070 0A 44 61 74 65 3A 20 57 65 64 2C 20 32 38 20 4A .Date:.Wed,.28.J
00000080 61 6E 20 32 30 30 39 20 32 30 3A 33 36 3A 33 36 an.2009.20:36:36
00000090 20 47 4D 54 0D 0A 43 6F 6E 6E 65 63 74 69 6F 6E .GMT..Connection
000000A0 3A 20 63 6C 6F 73 65 0D 0A 43 6F 6E 74 65 6E 74 :.close..Content
000000B0 2D 4C 65 6E 67 74 68 3A 20 34 34 0D 0A 0D 0A 3C -Length:.44....<
000000C0 68 31 3E 42 61 64 20 52 65 71 75 65 73 74 20 28 h1>Bad.Request.(
000000D0 48 65 61 64 65 72 20 46 69 65 6C 64 20 54 6F 6F Header.Field.Too
000000E0 20 4C 6F 6E 67 29 3C 2F 68 31 3E 01 02 03 04 05 .Long).....
000000F0 05 06 0E 94 63 D6 68 37 1B 8C 16 FE 3F D5       ....c.h7....?.

È possibile notare che il testo del messaggio di errore visualizzato nel browser è anche visualizzabile nei dati di risposta non elaborati nella traccia di rete.

Il passaggio successivo consiste nell'esaminare il file httperr.log nella directory C:\Windows\System32\LogFiles\HTTPERR per la voce che corrisponde alla richiesta non valida:

#Software: Microsoft HTTP API 1.0
#Version: 1.0
#Date: 2012-11-14 20:35:02
#Fields: date time cs-version cs-method cs-uri sc-status s-reason 
2012-11-14 20:36:36 HTTP/1.1 GET /1234567890/time.asp 400 FieldLength

In questo scenario, il Reason campo nel file di httperr.log fornisce le informazioni esatte necessarie per diagnosticare il problema. Si noterà che HTTP.sys registrato FieldLength come frase motivo per l'errore della richiesta. Dopo aver appreso la frase motivo, controllare la tabella in Tipi di errori nella sezione Log API HTTP per ottenere la relativa descrizione:

FieldLength: è stato superato un limite di lunghezza del campo.

A questo punto si sa dal messaggio di errore del browser e dalla registrazione degli errori dell'API HTTP che la richiesta conteneva dati in una delle intestazioni HTTP che superano i limiti di lunghezza consentiti. Per questo esempio, l'oggetto HTTP: Uniform Resource Identifier header è intenzionalmente lungo: /1234567890123456789012345678901234567890/time.asp.

La fase finale della risoluzione dei problemi di questo esempio consiste nel controllare le chiavi del Registro di sistema HTTP.sys e le impostazioni predefinite per IIS

Poiché si conosce la frase motivo e l'errore suggerisce una lunghezza del campo di intestazione che supera i limiti, è possibile restringere la ricerca nella tabella Chiavi del Registro di sistema, come tale. Il candidato primo è:

Chiave del Registro di sistema Default value Intervallo di valori valido Funzione chiave del Registro di sistema Codice AVVISO
MaxFieldLength 16384 64 - 65534 (64k - 2) byte Imposta un limite superiore per ogni intestazione. Vedere MaxRequestBytes. Questo limite si traduce in circa 32.000 caratteri per un URL. 1

Per riprodurre questo errore per questo esempio, la MaxFieldLength chiave del Registro di sistema è stata impostata con il valore 2. Poiché l'URL richiesto aveva un HTTP: Uniform Resource Identifier header campo con più di due caratteri, la richiesta è stata bloccata con la FieldLength frase motivo.

Un altro scenario HTTP 400 comune è quello in cui l'utente che effettua la richiesta HTTP è membro di un numero elevato di gruppi di Active Directory e il sito Web è configurato per l'autenticazione Kerberos dell'utente. Quando si verifica questo scenario, all'utente verrà visualizzato un messaggio di errore simile al seguente:

Richiesta non valida (intestazione richiesta troppo lunga)

In questo scenario, il token di autenticazione incluso nell'ambito della richiesta HTTP del client è troppo grande e supera i limiti di dimensioni che http.sys impone. Questo problema viene descritto in dettaglio, insieme alla soluzione, nelle risposte HTTP 400 - Richiesta non valida (intestazione richiesta troppo lunga) alle richieste HTTP.

Riferimenti