Come usare errori dettagliati HTTP in IIS 7.0
di IIS Team
Introduzione
Ogni amministratore Web-Site o sviluppatore Web ha visualizzato i messaggi "404 - File non trovato", "401 - Non autorizzato" o "500 - Errore server" nel browser. Questo articolo illustra come e perché IIS genera questi errori e come possono essere configurati.
Molti potrebbero pensare che la generazione di messaggi di errore non sembra giustificare un articolo completo. Ma c'è più di errori che incontra l'occhio. I messaggi di errore sono un argomento sensibile, perché ogni errore rivela più informazioni sul sito Web di quanto si voglia rivelare. Più informazioni qualcuno può raccogliere sul tuo sito, il più simile è che sarai hacked. Una ricerca di "google hacking" o "cross-site scripting" rivela una vasta gamma di informazioni su questo argomento.
Tuttavia, i messaggi di errore sono anche uno strumento utile per risolvere i problemi. Gli sviluppatori e gli amministratori di Web-Site richiedono il maggior numero possibile di dettagli quando si verifica un errore. Idealmente, il messaggio di errore fornisce consigli su come risolvere il problema. Ecco come IIS affronta questi obiettivi fondamentalmente opposti.
Errori, quali errori?
Questo articolo illustra gli errori HTTP come specificato nella RFC HTTP (RFC 2616 - sezione 6.1.1). Un errore HTTP viene sempre espresso inviando una risposta con un codice di stato maggiore di 400 al client richiedente.
Errori client
I codici di stato compresi tra 400 e 500 specificano un errore che il client ha effettuato, ad esempio una sintassi non valida o una richiesta a una risorsa che non esiste. È possibile provare questa operazione richiedendo un URL fittizio dal sito Web preferito, ad esempio http://< IIS7Server>/this_resource_does_not_exist. Viene visualizzato un errore "404 - File non trovato".
Errori server
I codici di stato a partire da 500 sono errori causati dal server. Le cause più comuni per 500 errori nei sistemi IIS sono:
- Pagina ASP o ASPX contenente un errore di sintassi
- La configurazione del server Web o la configurazione dell'applicazione non può essere letta o non è valida
- Il sito viene arrestato
È importante notare che i browser come Internet Explorer spesso sostituiscono gli errori restituiti da un server Web con i propri errori. Ciò rende più difficile la risoluzione dei problemi. In Internet Explorer è possibile disattivare questa funzionalità. Passare al menu "Strumenti", selezionare "Opzioni Internet", fare clic sulla scheda "Avanzate" e trovare la casella di controllo "Mostra messaggi di errore HTTP descrittivi" e deselezionarla. Per visualizzare la risposta non elaborata, usare strumenti HTTP come WFETCH in IIS 6.0 Resource Kit (vedere "Collegamenti correlati").
Errori HTTP in IIS
Quando il modulo httpError (custerr.dll) rileva un errore, è possibile eseguire due operazioni:
- Viene generato un errore personalizzato
- Viene generato un errore dettagliato
Gli errori personalizzati sono pagine di errore visualizzate dai normali utenti del sito Web. Contengono una breve descrizione dell'errore del motivo per cui si è verificato l'errore, ma nient'altro. Di seguito è riportato l'errore personalizzato generato quando si richiede una risorsa che non esiste, ad esempio: http://< IIS7Server>/this_resource_does_not_exist
Gli errori dettagliati sono destinati a amministratori e sviluppatori locali. Dovrebbero fornire informazioni utili per risolvere immediatamente il problema. Di seguito è riportato un esempio della stessa richiesta, ma ora viene restituito un errore dettagliato:
Questo è pericoloso, perché gli errori dettagliati contengono informazioni sui lavori interni del sito Web. Solo il personale attendibile dovrebbe visualizzare un errore dettagliato. L'unico modo per garantire questo problema consiste nel generare un errore dettagliato solo se la richiesta proviene dal computer locale. Non appena la richiesta non è locale, viene generato un errore personalizzato. Esaminare il diagramma di flusso seguente:
Flusso di dati
First: Error check
Il modulo httpError riceve una notifica se una risposta sta per essere inviata (RQ_SEND_RESPONSE notifica). Il modulo httpError controlla il codice di stato di questa risposta e restituisce immediatamente se il codice di stato non è maggiore di 400.
Secondo: errore personalizzato o errore dettagliato
Il controllo successivo è determinato dall'origine della richiesta (è la richiesta di una richiesta locale o remota) e dall'impostazione della proprietà errorMode. La proprietà errorMode è impostata su DetailedLocalOnly, il che significa che vengono generati errori personalizzati per ogni richiesta remota. Se errorMode è impostato su "Custom", tutte le risposte di errore diventeranno Errore personalizzato. Se errorMode è impostato su "Dettagliato" tutte le risposte di errore diventeranno Errori dettagliati. La tabella seguente illustra questo comportamento:
| Errormode | Origine richiesta | Azione |
|---|---|---|
| DetailedLocalOnly (impostazione predefinita) | Locale | Errore dettagliato |
| DetailedLocalOnly (impostazione predefinita) | Remoto | Errore personalizzato |
| Personalizzato | Locale | Errore personalizzato |
| Personalizzato | Remoto | Errore personalizzato |
| Dettagliato | Locale | Errore dettagliato |
| Dettagliato | Remoto | Errore dettagliato |
Se il modulo httpError determina che deve essere generato un errore personalizzato, esamina la configurazione per verificare se è in grado di trovare un errore corrispondente. Se viene trovata una corrispondenza, invia il file statico, reindirizza la richiesta o esegue l'URL specificato. Se non viene trovata alcuna corrispondenza, IIS invia un messaggio di base a una riga contenente il codice di stato. La sezione successiva illustra in dettaglio la configurazione dell'errore personalizzato.
Se custerr.dll determina che deve essere generato un errore dettagliato, è necessario un altro controllo. IIS non tocca la risposta se un modulo esegue l'overrode dell'entità della risposta con la relativa descrizione dell'errore. Potrebbe contenere informazioni preziose. ASP.NET è un buon esempio. L'entità di una risposta di errore ASP.NET potrebbe contenere lo stack di eccezioni e la relativa descrizione dell'errore. Viene generato un errore dettagliato solo se il corpo dell'entità della risposta è vuoto.
<httpErrors> Configurazione
Di seguito è riportata la sezione relativa all'errore personalizzato IIS ottenuta in un'installazione pulita:
<httpErrors>
<error statusCode="401" prefixLanguageFilePath="c:\inetpub\custerr" path="401.htm" />
<error statusCode="403" prefixLanguageFilePath="c:\inetpub\custerr" path="403.htm" />
<error statusCode="404" prefixLanguageFilePath="c:\inetpub\custerr" path="404.htm" />
<error statusCode="405" prefixLanguageFilePath="c:\inetpub\custerr" path="405.htm" />
<error statusCode="406" prefixLanguageFilePath="c:\inetpub\custerr" path="406.htm" />
<error statusCode="412" prefixLanguageFilePath="c:\inetpub\custerr" path="412.htm" />
<error statusCode="500" prefixLanguageFilePath="c:\inetpub\custerr" path="500.htm" />
<error statusCode="501" prefixLanguageFilePath="c:\inetpub\custerr" path="501.htm" />
<error statusCode="502" prefixLanguageFilePath="c:\inetpub\custerr" path="502.htm" />
</httpErrors>
Si noterà che se il codice di stato di una risposta è 401, IIS restituirà un file denominato 401.htm.
Codici Sub-Status
Molti errori HTTP hanno uno stato secondario. La configurazione predefinita degli errori personalizzati di IIS non distingue i codici di stato secondari basati. Invia la stessa pagina Errore personalizzato se si immettono le credenziali errate (401.1) o se l'accesso viene negato in base ai diritti non validi per accedere a un file (401.3). È possibile visualizzare i diversi codici di stato secondari nei file di log o tramite errori dettagliati. Ecco un elenco dei diversi codici di stato secondario 404 prodotti da IIS:
| Stato | Descrizione |
|---|---|
| 404.1 | Impossibile trovare il sito |
| 404.2 | Negata dai criteri. Il programma ISAPI o CGI della richiesta non è consentito nell'elenco delle restrizioni. |
| 404.3 | Il gestore di file statici non ha ottenuto il file in MimeMap e quindi ha rifiutato la richiesta. |
| 404.4 | Non è stato trovato alcun gestore per la gestione della richiesta. |
| 404.5 | Il modulo di filtro richieste ha rifiutato una sequenza di URL nella richiesta. |
| 404.6 | Il modulo di filtro richieste ha negato il verbo HTTP della richiesta. |
| 404.7 | Il modulo Filtro richieste ha rifiutato l'estensione di file della richiesta. |
| 404.8 | Il modulo Filtro richieste ha rifiutato un particolare segmento di URL (caratteri tra due barre). |
| 404.9 | IIS ha rifiutato di gestire un file nascosto. |
| 404.11 | Il modulo Filtro richieste ha rifiutato una richiesta con carattere di escape doppio. |
| 404.12 | Il modulo Filtro richieste ha rifiutato una richiesta contenente caratteri di bit elevati. |
| 404.14 | Il modulo Filtro richieste ha rifiutato una richiesta con un URL troppo lungo. |
| 404.15 | Il modulo Filtro richieste ha rifiutato una richiesta con una stringa di query troppo lunga. |
| 413.1 | Il modulo Filtro richieste ha rifiutato una richiesta troppo lunga (richiesta + corpo dell'entità). |
| 431 | Il modulo Filtro richieste ha rifiutato un'intestazione troppo lunga. |
È possibile configurare la sezione httpErrors per visualizzare un errore personalizzato per determinati codici di stato secondari. Se si aggiunge la riga seguente alla sezione di configurazione httpErrors, IIS restituisce 404_3.htm se viene richiesto un file con estensione di file non incluso nella sezione IIS MimeMap (<configurazione staticContent> ).
<error statusCode="404" subStatusCode="3" prefixLanguageFilePath="c:\inetpub\custerr" path="404_3.htm" />
Ecco come eseguire l'esempio:
- Aggiungere la voce precedente alla sezione di configurazione httpErrors.
- Creare un file denominato 404_3.htm nella
c:\inetpub\custerr\en-usdirectory. - Creare un file denominato test.yyy nella
c:\inetpub\wwwrootdirectory. http://localhost/test.yyyRichiedere ora .
L'estensione di file yyy non fa parte di IIS MimeMap e il gestore di file statico non lo servirà.
Novità di IIS: Errori personalizzati specifici del linguaggio
Ogni browser più recente include la lingua del client come intestazione della richiesta. Di seguito è riportato un esempio dell'aspetto dell'intestazione:
Accept-Language: en-us
La sintassi e il Registro di sistema dei linguaggi accettati sono specificati in RFC1766.
Quando si genera un errore, IIS prende in considerazione questa intestazione quando cerca il file di errore personalizzato restituito. Genera il percorso dell'errore personalizzato usando la logica seguente:
impostazione di configurazione prefixLanguageFilePath (ad esempio c:\inetpub\custerr)+
Accept-Language'intestazione inviata dal client (ad esempio en-us) +
Impostazione di configurazione del percorso (ad esempio 404.htm)
Esempio:
Se il browser invia una richiesta per una risorsa non esistente e l'intestazione "Accept-Language" ha il valore "en-us", il file restituito sarà c:\inetpub\custerr\en-us\404.htm.
Ad esempio, se si proviene da Germania, si desidera che i messaggi di errore siano in tedesco. A tale scopo, è necessario installare il Language Pack di Windows Vista per il tedesco. In questo modo viene creata la c:\inetpub\custerr\de-DE directory con file di errore personalizzati. Ora se il browser invia l'intestazione "Accept-Language" con il valore "de-DE", il file restituito sarà c:\inetpub\custerr\de-DE\404.htm.
IIS eseguirà sempre il fallback alla lingua di sistema se la directory "de-DE" non esiste.
Nota
Internet Explorer consente di configurare l'intestazione Accept-Language. Passare a "Strumenti" - "Opzione Internet", selezionare la scheda "Generale" e fare clic sul pulsante "Lingue".
Opzioni di errore personalizzate
Negli esempi precedenti IIS invia il contenuto del file come risposta di errore personalizzata. IIS offre due altri modi per rispondere a un errore: eseguendo un URL o reindirizzando la richiesta.
ExecuteUrl
Se si desidera eseguire altre operazioni nell'errore personalizzato, ad esempio l'invio di un messaggio di posta elettronica o la registrazione dell'errore in un database, è possibile eseguire un URL. In questo modo è possibile eseguire contenuto dinamico come una pagina di ASP.NET. L'esempio seguente sostituisce l'errore personalizzato 404. IIS esegue ora /404.aspx ogni volta che si verifica un errore 404.
<httpErrors>
<!-- default custom error for 401 errors -->
<!-- <error statusCode="404" prefixLanguageFilePath="c:\inetpub\custerr" path="404.htm" />-->
<!-- ExecuteURL replaces default file response mode -->
<error statusCode="404" path=/404.aspx" responseMode="ExecuteURL"/>
<error statusCode="403" prefixLanguageFilePath="c:\inetpub\custerr" path="403.htm" />
<error statusCode="404" prefixLanguageFilePath="c:\inetpub\custerr" path="404.htm" />
<error statusCode="405" prefixLanguageFilePath="c:\inetpub\custerr" path="405.htm" />
<error statusCode="406" prefixLanguageFilePath="c:\inetpub\custerr" path="406.htm" />
<error statusCode="412" prefixLanguageFilePath="c:\inetpub\custerr" path="412.htm" />
<error statusCode="500" prefixLanguageFilePath="c:\inetpub\custerr" path="500.htm" />
<error statusCode="501" prefixLanguageFilePath="c:\inetpub\custerr" path="501.htm" />
<error statusCode="502" prefixLanguageFilePath="c:\inetpub\custerr" path="502.htm" />
</httpErrors>
Considerazioni relative alla sicurezza
Una parola di cautela: per motivi architetturali, IIS può eseguire l'URL solo se si trova nello stesso pool di applicazioni. Usare la funzionalità di reindirizzamento per eseguire un errore personalizzato in un pool di applicazioni diverso.
IIS può anche restituire un reindirizzamento 302 al browser quando si verifica un errore specifico. Il reindirizzamento è valido se si dispone di una server farm. Ad esempio, è possibile reindirizzare tutti gli errori a una posizione centrale monitorata da vicino.
Esiste tuttavia un rischio: responseMode="File" (che è l'impostazione predefinita) consente di specificare ogni file sul disco. Questo non funzionerà se sei molto consapevole della sicurezza.
Uno scenario utilizzabile può includere solo la delega dell'impostazione errorMode. In questo modo uno sviluppatore può ricevere errori dettagliati per l'applicazione anche se usa un client remoto. Tutto ciò che è necessario è impostare errorMode="Detailed". Ecco come configurare questo scenario:
Consentire la delega della sezione httpErrors:
<section name="httpErrors" overrideModeDefault="Allow" />
In secondo luogo, passare alla <httpErrors> sezione in applicationHost.config e modificarla in modo che venga delegato solo errorMode:
<httpErrors lockAllAttributesExcept="errorMode" lockElements="error">
<error statusCode="404" prefixLanguageFilePath="E:\inetpub\custerr" path="404.htm" />
<error statusCode="401" prefixLanguageFilePath="E:\inetpub\custerr" path="401.htm" />
<error statusCode="403" prefixLanguageFilePath="E:\inetpub\custerr" path="403.htm" />
<error statusCode="405" prefixLanguageFilePath="E:\inetpub\custerr" path="405.htm" />
<error statusCode="406" prefixLanguageFilePath="E:\inetpub\custerr" path="406.htm" />
<error statusCode="412" prefixLanguageFilePath="E:\inetpub\custerr" path="412.htm" />
<error statusCode="500" prefixLanguageFilePath="E:\inetpub\custerr" path="500.htm" />
<error statusCode="501" prefixLanguageFilePath="E:\inetpub\custerr" path="501.htm" />
<error statusCode="502" prefixLanguageFilePath="E:\inetpub\custerr" path="502.htm" />
</httpErrors>
Riepilogo
Gli errori personalizzati e dettagliati sono potenti funzionalità iis. Consentono di risolvere i problemi senza compromettere la sicurezza del server IIS. Molte opzioni di configurazione consentono di personalizzare l'esperienza degli utenti. Soprattutto: sperimentare con esso è divertente.