Qual è la differenza tra customErrors e httpErrors?

Qual è la differenza tra le sezioni customErrors e httpErrors del file web.config nelle applicazioni ASP.NET MVC?

Quali sono le linee guida per l’utilizzo di ciascuna sezione?

Disclaimer: questo è dalla mia esperienza e fatto non dimostrato.

Entrambi sono utilizzati per definire la gestione degli errori per un sito Web, ma diversi software si riferiscono a diversi elementi di configurazione.

customErrors è un elemento legacy (retrocompatibile), utilizzato da Visual Studio Development Server (noto come VSDS o Cassini).

httpErrors è il nuovo elemento che viene utilizzato solo da IIS7.

Ciò evidenzia il ansible problema durante lo sviluppo di siti Web ASP.NET mentre si utilizza VSDS anziché IIS locale.

Inoltre, riferirsi a questo post da solo su come gestire i messaggi di errore con IIS7, se si desidera avere il pieno controllo dell’output dell’errore.

Sommario:

  • Sviluppando in VSDS – usa customErrors
  • Pubblicazione del sito su IIS6 : utilizzare customErrors
  • Pubblicazione del sito su IIS7 : utilizzare httpErrors .

e se sviluppate con VSDS ma pubblicate su IIS7 , suppongo che avrete bisogno di entrambi.

* Aggiornato ad aprile 2016

L’attributo customErrors viene utilizzato quando il codice .net genera un’eccezione (404, 403, 500 ecc.) E l’attributo httpErrors viene utilizzato quando IIS genera un’eccezione.

  • / myfakeextensionslessurl -> httpErrors 404
  • /myfakeaspsx.aspx -> customErrors 404
  • /myfakeimage.jpg -> httpErrors 404
  • /throw500.apx -> customErrors 500
  • / throw500 -> customErrors 500

Ci sono molte insidie ​​che cercano di configurarlo correttamente. Quindi, se stai cercando un esempio veloce, le 2 migliori opzioni disponibili sono:

Esempio 1: utilizzo di pagine html

                  

Esempio 2: utilizzo di pagine aspx

                  

E nelle pagine di errore di aspx devi fare qualcosa del genere (pagina 404 di esempio):

 <% Response.StatusCode = 404; Response.TrySkipIisCustomErrors = true; %> 

Nota: l’utilizzo dell’estensione meno url nella sezione CustomErrors non è ansible! . (senza hack)

Una soluzione è disabilitare gli errori personalizzati e lasciare che gli errori http gestiscano la pagina personalizzata. Un amico ha creato tale configurazione, quando trovo un po ‘di tempo, condividerò il codice.

sfondo

Una buona pagina di errore personalizzata:

  1. Mostra la vera eccezione quando visiti la pagina del problema localmente
  2. Mostra una pagina personalizzata quando visiti la pagina del problema da remoto
  3. Non reindirizzerà, ma mostrerà semplicemente il contenuto della pagina di errore (a causa di motivi seo)
  4. Mostrerà il codice di stato corretto

Quindi per chiarire alcune opzioni nella nostra configurazione:

  1. customErrors mode = “RemoteOnly”. È ansible specificare qui: On, Off, RemoteOnly. On = Mostra sempre pagine di errore personalizzate, Off = Mostra sempre l’errore reale, RemoteOnly = Mostra localmente l’errore, ma mostra la pagina di errore personalizzata in remoto. Quindi vogliamo RemoteOnly per la dichiarazione 1
  2. customeErrors redirectMode = “ResponseRewrite”. È ansible specificare qui: ResponseRedirect, ResponseRewrite. Il modus ResponseRedirect reindirizzerà la pagina di errore alla pagina di errore personalizzata. Per un crawler di link (seo) ciò si tradurrà in 302 -> 500. Mentre si vuole che il crawler di link ottenga semplicemente un errore di 500.
  3. httpErrors errorMode = “DetailedLocalOnly”, questo è l’equalizzatore della modalità customErrors. Opzioni che hai: personalizzato, dettagliato, dettagliatoLocalOnly

Un buon post sul blog che mi ha aiutato molto è: http://benfoster.io/blog/aspnet-mvc-custom-error-pages

rispetto a


  • ancora disponibile in IIS7 +
  • specificare le pagine di errore personalizzate per le richieste gestite da ASP.NET
  • gestisce solo le richieste all’interno dell’applicazione ASP.NET
  • i file statici come i file HTML o gli URL di directory (“amichevoli”) non vengono gestiti

  • introdotto in IIS7
  • specificare le pagine di errore personalizzate per le richieste gestite da IIS
  • gestisce le richieste all’interno dell’applicazione ASP.NET AND / OR gestisce le richieste all’esterno dell’applicazione – ASP.NET *
  • tutti i file e gli URL sono gestiti *

Nota: non è più necessario utilizzare customErrors

Fonte citata: 404 personalizzata e pagine di errore in ASP.NET (articolo eccellente)


ExecuteURL offre contenuti dinamici come una pagina .aspx (il valore del path deve essere un URL relativo al server ):

       

File serve un file di errore personalizzato, ad esempio una pagina .html:

       

Riferimento: errori HTTP (www.iis.net)

per maggiori dettagli, leggi il link http://www.iis.net qui sopra

La sezione Errori nella configurazione web serve a fornire un approccio di gestione degli errori http personalizzato. Ci sono due sezioni, una CustomErrors all’interno della sezione system.web e un’altra httpErrors all’interno della sezione system.webServer (come indicato di seguito)

customErrors: questa sezione era in uso prima dell’introduzione di IIS 7, IIS 6 5 e prima di utilizzare completamente questa sezione per la gestione degli errori http personalizzati in base al codice di stato http.

httpErrors: IIS 7 e versioni successive utilizzano questa sezione nonché la sezione CustomErrors per gestire gli errori http personalizzati in base alle estensioni dei file se l’estensione della pagina richiesta si registra con dll ISAPI (.aspx, ashx, .asmx, .svc ecc) come index.aspx quindi Impostazioni di raccolta di IIS dalla sezione customeErrors altrimenti riprende le impostazioni da httpErrors (la modalità host di IIS 7 deve essere impostata come mood integrato non classico)

di seguito sono riportati gli esempi per il link di controllo della gestione degli errori 404:

httperrors vs customerrors in webconfig, iis, asp.net