#958 - Gestione degli errori e HttpContext con ASP.NET 3.5 SP1
Con il SP1 del .NET Framework 3.5 è possibile modificare a runtime l'HttpHandler designato per la gestione di una determinata richiesta HTTP, grazie all'introduzione del metodo RemapHandler:
HttpContext.Current.RemapHandler(nuovoHandler);
Tipicamente, esso viene invocato all'interno di un HttpModule che, in base ad alcune condizioni e comunque prima dell'evento MapRequestHandler, può decidere di elaborare la risposta tramite un handler differente da quello specificato nel web.config. Un esempio può essere quello della sezione Press di un sito web, contenente gallerie di immagini che devono essere presentate con o senza un watermark attestante il copyright, a seconda che l'utente sia autenticato (e magari paghi un abbonamento per lo sfruttamento dei diritti) o meno.
L'esempio allegato utilizza l'handler WatermarkedImageHandler per aggiungere un watermark alle immagini JPEG, impostandolo all'interno del file di configurazione come handler di default per questo tipo di file (ovviamente dopo aver avuto cura di configurare correttamente IIS per servire i file .jpg tramite il worker process di ASP.NET):
<add verb="*" path="*.jpg"
type="Sp1SampleLibrary.WatermarkedImageHandler, Sp1SampleLibrary" />
Inoltre registra anche un HttpModule:
<add name="ImageModule" type="Sp1SampleLibrary.ImageModule, Sp1SampleLibrary" />
che, nel caso in cui l'utente risulti autenticato, si avvale di HttpContext.RemapHandler per inoltrare la richiesta ad un secondo HttpHandler, chiamato PlainImageHandler, mostrando in questo modo l'immagine originale, priva di watermark:
static void context_PostAuthenticateRequest(object sender, EventArgs e)
{
HttpContext context = HttpContext.Current;
string phisicalPath = context.Request.PhysicalPath;
bool authenticated = context.User != null &&
context.User.Identity != null &&
context.User.Identity.IsAuthenticated;
if (Path.GetExtension(phisicalPath).ToLower().EndsWith("jpg") &&
authenticated)
HttpContext.Current.RemapHandler(new PlainImageHandler());
}
Un'altra novità del SP 1 riguarda invece il file web.config, ed in particolare la sezione CustomErrors. Grazie all'attributo redirectMode è ora possibile decidere se, nel redirect ad una pagina custom di errore, l'URL mostrato nella finestra del browser debba variare (ResponseRedirect) o rimanere il medesimo della pagina che ha sollevato l'eccezione (ResponseRewrite).
<customErrors mode="On" redirectMode="ResponseRewrite">
<error statusCode="500" redirect="CustomErrorPage.aspx"/>
</customErrors>
Quest'ultima impostazione è particolarmente comoda in quanto consente, alla ricezione di un messaggio di errore, di tentare un refresh della pagina semplicemente premendo F5 invece che essere costretti a navigare nella history del browser come accadeva precedentemente, oltre a consentire in maniera più semplice di gestire eventuali codici HTTP di errore.
Approfondimenti
- Speciale ASP.NET security
- #920 - Utilizzare HttpModule in modalità asincrona
- Speciale .NET Framework 3.5 SP1
- Introduzione ad ASP.NET 3.5
- #955 - Realizzare un metodo FindControl generico utilizzando gli Extension Method
- #963 - Intercettare gli eventi LoadComplete e PreRenderComplete da uno user control
- #923 - Caricare dinamicamente un HttpModule
- #954 - Impostare a runtime la query di selezione con SqlDataSource
- ASP.NET 3.5 Extensions: MVC, history e Dynamic Data Controls
- Prima October Preview per ASP.NET 4.0
- I bug di ASP.NET AJAX 1.0 risolti con ASP.NET AJAX 3.5
Commenti
Esprimi il tuo giudizio su questo script:
Per procedere devi essere autenticato.
Aggiungi un nuovo commento »»»
Per inserire un commento, devi registrarti alla nostra community.
Stampa 
Download
10annidi.ASPItalia.com: iscriviti alla competizione e vinci fantastici premi ogni mese!