Condividi tramite


Cenni preliminari su gestori HTTP e moduli HTTP

Aggiornamento: novembre 2007

Un gestore HTTP ASP.NET rappresenta il processo, comunemente definito endpoint, eseguito in risposta a una richiesta inviata a un'applicazione Web ASP.NET. Il gestore più comune è un gestore di pagina ASP.NET che elabora i file con estensione aspx. Quando gli utenti richiedono un file aspx, la richiesta viene elaborata dalla pagina mediante il relativo gestore. È possibile creare gestori HTTP che eseguano il rendering dell'output personalizzato nel browser.

Un modulo HTTP è un assembly che viene chiamato in occasione di ogni richiesta inviata all'applicazione. I moduli HTTP vengono chiamati nell'ambito della pipeline di richieste ASP.NET e hanno accesso agli eventi del ciclo di vita della richiesta. Pertanto, consentono di esaminare le richieste in arrivo e in uscita e di eseguire azioni in base ad esse.

Vengono illustrati i seguenti argomenti:

  • Scenari

  • Funzionalità dei gestori HTTP e dei moduli HTTP

  • Informazioni di supporto

  • Esempi di codice

  • Riferimento alle classi

Scenari

Gli utilizzi tipici dei gestori HTTP personalizzati sono i seguenti:

  • Feed RSS   Per creare un feed RSS per un sito Web, è possibile creare un gestore che generi XML in formato RSS. È quindi possibile associare un'estensione di file, ad esempio rss, al gestore personalizzato. Quando gli utenti inviano al sito una richiesta che termina con l'estensione rss, ASP.NET chiama il gestore per elaborare la richiesta.

  • Server immagini   Se si desidera che un'applicazione Web fornisca immagini in diverse dimensioni, è possibile scrivere un gestore personalizzato per ridimensionare le immagini e quindi inviarle all'utente come risposta del gestore.

Gli utilizzi tipici dei moduli HTTP sono i seguenti:

  • Sicurezza   Poiché è possibile esaminare le richieste in arrivo, un modulo HTTP consente di eseguire l'autenticazione personalizzata o altri controlli di sicurezza prima che la pagina, il servizio Web XML o il gestore richiesto venga chiamato. In Internet Information Services (IIS) 7.0 in esecuzione in modalità di integrazione è possibile estendere l'autenticazione basata su form a tutti i tipi di contenuto di un'applicazione.

  • Statistiche e registrazione   Poiché i moduli HTTP vengono chiamati a ogni richiesta, è possibile raccogliere statistiche e informazioni di registrazione in un modulo centralizzato invece che in singole pagine.

  • Intestazioni o piè di pagina personalizzati   Poiché la risposta in uscita può essere modificata, è possibile inserire contenuto quale le informazioni sull'intestazione personalizzata in ogni pagina o risposta del servizio Web XML.

Torna all'inizio

Funzionalità

Le funzionalità dei gestori e dei moduli HTTP sono le seguenti:

  • Le interfacce IHttpHandler e IHttpModule sono il punto di partenza per lo sviluppo di gestori e moduli.

  • L'interfaccia IHttpAsyncHandler è il punto di partenza per lo sviluppo dei gestori asincroni.

  • Il codice sorgente dei gestori personalizzati e dei moduli può essere inserito nella cartella App_Code di un'applicazione o compilato e inserito nella cartella Bin di un'applicazione.

  • I gestori e i moduli sviluppati per IIS 6.0 possono essere utilizzati in IIS 7.0 con poche modifiche o persino nessuna modifica. Per ulteriori informazioni, vedere Spostamento di un'applicazione ASP.NET da IIS 6.0 a IIS 7.0.

  • I moduli possono sottoscrivere diverse notifiche di pipeline di richieste e possono ricevere la notifica di eventi dell'oggetto HttpApplication.

  • In IIS 7.0, la pipeline di richieste è integrata con la pipeline di richieste del server Web. I moduli HTTP possono essere utilizzati per qualsiasi richiesta al server Web, non solo per le richieste ASP.NET.

Torna all'inizio

Informazioni di supporto

Gestori HTTP

Un gestore HTTP ASP.NET è il processo eseguito in risposta a una richiesta inviata a un'applicazione Web ASP.NET. Il gestore più comune è un gestore di pagina ASP.NET che elabora i file con estensione aspx. Quando gli utenti richiedono un file aspx, la richiesta viene elaborata dal gestore di pagina.

Il gestore di pagina ASP.NET rappresenta uno dei tipi di gestori disponibili. ASP.NET include diversi altri gestori incorporati, come il gestore dei servizi Web per i file asmx.

Gestori HTTP incorporati in ASP.NET

ASP.NET esegue il mapping delle richieste HTTP ai gestori HTTP in base all'estensione dei file. Ciascun gestore HTTP è in grado di elaborare URL HTTP singoli o gruppi di estensioni URL di un'applicazione. ASP.NET include diversi gestori HTTP incorporati, come elencato nella tabella riportata di seguito.

Gestore

Descrizione

Gestore di pagina ASP.NET (*.aspx)

Gestore HTTP predefinito per tutte le pagine ASP.NET

Gestore di servizi Web (*.asmx)

Gestore HTTP predefinito per le pagine dei servizi Web create come file asmx in ASP.NET.

Gestore Web generico (*.ashx)

Gestore HTTP predefinito per tutti i gestori Web privi di interfaccia utente e che includono la direttiva @ WebHandler.

Gestore di analisi (trace.axd)

Gestore che visualizza le informazioni relative all'analisi della pagina corrente. Per informazioni dettagliate, vedere Procedura: visualizzare le informazioni di analisi di ASP.NET con il visualizzatore di analisi.

Creazione di un gestore HTTP personalizzato

Per creare un gestore HTTP personalizzato, si crea una classe che implementi l'interfaccia IHttpHandler per creare un gestore asincrono. In alternativa, per creare un gestore asincrono è possibile implementare IHttpAsyncHandler. Per entrambe le interfacce di gestori è necessario implementare la proprietà IsReusable e il metodo ProcessRequest. La proprietà IsReusable specifica se l'oggetto IHttpHandlerFactory (l'oggetto che effettivamente chiama il gestore appropriato) può inserire il gestore in un pool e riutilizzarlo per aumentare le prestazioni. Se il gestore non può essere inserito in un pool, la factory deve creare una nuova istanza del gestore ogni volta che quest'ultimo è necessario.

Il metodo ProcessRequest si occupa di elaborare le singole richieste HTTP. In questo metodo si scrive il codice che produce l'output per il gestore.

I gestori HTTP hanno accesso al contesto dell'applicazione, inclusi l'identità (se nota) dell'utente richiedente, lo stato dell'applicazione e le informazioni sulla sessione. Quando si rende necessario un gestore HTTP, ASP.NET chiama il metodo ProcessRequest del gestore appropriato. Il codice scritto nel metodo ProcessRequest del gestore crea una risposta, che viene rinviata al browser richiedente.

Mapping di un'estensione di file

Quando si crea un file di classe come gestore HTTP, il gestore può rispondere a qualsiasi estensione di file non ancora mappata in IIS e in ASP.NET. Se ad esempio si crea un gestore HTTP per la generazione di un feed RSS, è possibile eseguire il mapping del gestore all'estensione rss. Affinché ASP.NET possa sapere quale gestore utilizzare per l'estensione di file personalizzata, in IIS è necessario eseguire il mapping dell'estensione ad ASP.NET. Quindi nell'applicazione è necessario eseguire il mapping dell'estensione al gestore personalizzato.

Per impostazione predefinita, ASP.NET esegue il mapping dell'estensione di file ashx a un gestore HTTP. Se si aggiunge la direttiva @ WebHandler a un file di classe, ASP.NET esegue automaticamente il mapping dell'estensione ashx al gestore HTTP predefinito. Questa operazione è simile al modo in cui ASP.NET esegue il mapping dell'estensione aspx al gestore di pagina ASP.NET quando viene utilizzata la direttiva @ Page. Se pertanto si crea una classe di gestore HTTP con l'estensione file ashx, il gestore viene automaticamente registrato con IIS e ASP.NET.

Se si desidera creare un'estensione di file personalizzata per un gestore, è necessario registrarla in modo esplicito con IIS e ASP.NET. Il vantaggio di non utilizzare l'estensione di file ashx è che il gestore è riutilizzabile per i mapping di estensioni diverse. Ad esempio, in un'applicazione il gestore personalizzato potrebbe rispondere alle richieste che terminano in rss. In un'altra applicazione potrebbe rispondere alle richieste che terminano in feed. Un altro esempio è dato dalla possibilità di eseguire il mapping del gestore a entrambe le estensioni di file nella stessa applicazione, ma creando risposte differenti in base all'estensione.

Il processo di registrazione dell'estensione di file di un gestore è diverso in IIS 7.0 e nelle versioni precedenti di IIS. Per ulteriori informazioni, vedere Procedura: registrare gestori HTTP e Procedura: configurare un'estensione del gestore HTTP in IIS.

Gestori HTTP asincroni e sincroni

Un gestore HTTP può essere sincrono o asincrono. Un gestore sincrono non restituisce alcun valore fino a quando non termina l'elaborazione della richiesta HTTP per la quale è stato chiamato. Un gestore asincrono esegue un processo indipendentemente dall'invio di una risposta all'utente. I gestori asincroni si rivelano utili se è necessario avviare un processo applicativo che potrebbe risultare lungo e non occorre attenderne il completamento prima di ottenere una risposta dal server.

I gestori HTTP asincroni consentono di avviare un processo esterno, ad esempio la chiamata a un metodo in un server remoto. Il gestore può quindi proseguire con l'elaborazione senza attendere la fine del processo esterno. Durante l'elaborazione di un gestore HTTP asincrono, ASP.NET inserisce il thread che verrebbe normalmente utilizzato per il processo esterno nel pool di thread finché il gestore non riceve un callback dal processo esterno. In questo modo si evita il blocco dei thread e si migliorano le prestazioni, in quanto è possibile eseguire contemporaneamente solo un numero limitato di thread. Se molti utenti richiedono gestori HTTP sincroni basati su processi esterni, è possibile che il sistema operativo esaurisca i thread perché molti di essi rimangono bloccati in attesa di un processo esterno.

Quando si crea un gestore asincrono, è necessario implementare l'interfaccia IHttpAsyncHandler. Occorre inoltre implementare il metodo BeginProcessRequest per avviare una chiamata asincrona che elabori le singole richieste HTTP. È inoltre necessario implementare il metodo EndProcessRequest per eseguire il codice di pulitura al termine del processo.

Classi IHttpHandlerFactory personalizzate

La classe IHttpHandlerFactory riceve le richieste ed è responsabile dell'inoltro di una richiesta al gestore HTTP appropriato. È possibile creare una factory di gestori HTTP personalizzati creando una classe che implementi l'interfaccia IHttpHandlerFactory. Tale creazione può fornire un maggiore controllo sull'elaborazione delle richieste HTTP mediante la creazione di gestori differenti in base alle condizioni in fase di esecuzione. Con una factory di gestori HTTP personalizzati, ad esempio, è possibile creare un'istanza di un gestore HTTP per un tipo di file se il metodo della richiesta HTTP è PUT e un altro gestore se il metodo è GET.

Per registrare un'estensione personalizzata per una factory di gestori, eseguire la procedura di registrazione di un'estensione personalizzata per un gestore. Per un esempio di creazione e registrazione di una factory di gestori, vedere Procedura dettagliata: creazione e registrazione di factory di gestori HTTP.

Moduli HTTP

Un modulo HTTP è un assembly che viene chiamato in occasione di ogni richiesta inviata all'applicazione. I moduli HTTP vengono chiamati nell'ambito della pipeline di richieste e hanno accesso agli eventi del ciclo di vita della richiesta. Pertanto, consentono di esaminare le richieste in arrivo e di eseguire azioni in base ad esse, nonché di esaminare e modificare la risposta in uscita.

In IIS 6.0, la pipeline di richieste ASP.NET è separata dalla pipeline di richieste del server Web. In IIS 7.0, la pipeline di richieste ASP.NET e la pipeline di richieste del server Web possono essere integrate in una pipeline di richieste comune. In IIS 7.0 vi si fa riferimento come modalità di integrazione. La pipeline unificata ha molti vantaggi per gli sviluppatori ASP.NET. Ad esempio, consente che i moduli di codice gestito riceve le notifiche della pipeline per tutte le richieste, anche se queste ultime non riguardano le risorse ASP.NET. Se tuttavia lo si desidera, è possibile eseguire IIS 7.0 in modalità classica, che emula ASP.NET in esecuzione in IIS 6.0. Per ulteriori informazioni, vedere Cenni preliminari sul ciclo di vita delle applicazioni ASP.NET per IIS 7.0.

I moduli HTTP ASP.NET sono simili ai filtri ISAPI per il fatto di essere richiamati per tutte le richieste, ma sono scritti in codice gestito e perfettamente integrati con il ciclo di vita di un'applicazione ASP.NET. È possibile inserire il codice sorgente dei moduli personalizzati nella cartella App_Code dell'applicazione oppure è possibile compilare i moduli personalizzati come assembly nella cartella Bin di un'applicazione.

In ASP.NET vengono utilizzati i moduli per implementare diverse funzionalità dell'applicazione, tra cui i servizi di autenticazione basata su form, memorizzazione nella cache, stato di sessione e script client. In ogni caso, quando questi servizi vengono attivati, il modulo viene chiamato come parte di una richiesta ed esegue attività esterne all'ambito di qualsiasi singola richiesta di pagina. I moduli possono utilizzare eventi di applicazioni nonché generare eventi gestibili nel file Global.asax. Per ulteriori informazioni sugli eventi di applicazione, vedere Cenni preliminari sul ciclo di vita delle applicazioni ASP.NET per IIS 5.0 e 6.0 e Cenni preliminari sul ciclo di vita delle applicazioni ASP.NET per IIS 7.0.

Nota:

I moduli HTTP sono diversi dalle intestazioni HTTP, Un gestore HTTP restituisce una risposta a una richiesta identificata da un'estensione di file o una famiglia di estensioni di file. Al contrario, un modulo HTTP viene richiamato per tutte le richieste e le risposte. Sottoscrive le notifiche degli eventi nella pipeline di richieste e consente di eseguire il codice nei gestori eventi registrati. Le attività per le quali un modulo viene utilizzato sono generali in un'applicazione e in tutte le richieste per le risorse dell'applicazione.

Modalità di funzionamento dei moduli HTTP

I moduli devono essere registrati per ricevere le notifiche dalla pipeline di richieste. La modalità più comune per registrare un modulo HTTP è nel file Web.config dell'applicazione. In IIS 7.0, la pipeline di richieste unificata consente inoltre di registrare un modulo in altri modi, tra cui Gestione IIS e lo strumento da riga di comando Appcmd.exe. Per ulteriori informazioni, vedere  Configuring Handler Mappings in IIS 7.0 e Start Appcmd.exe (informazioni in lingua inglese).

Quando ASP.NET crea un'istanza della classe HttpApplication che rappresenta l'applicazione, vengono create le istanze dei moduli registrati. Al momento della creazione di un modulo, ne viene chiamato il metodo Init e il modulo viene inizializzato. Per ulteriori informazioni, vedere Cenni preliminari sul ciclo di vita delle applicazioni ASP.NET per IIS 5.0 e 6.0 e Cenni preliminari sul ciclo di vita delle applicazioni ASP.NET per IIS 7.0.

All'interno del metodo Init di un modulo è possibile sottoscrivere diversi eventi di applicazione, come BeginRequest o EndRequest, mediante l'associazione degli eventi ai metodi nel modulo.

Nota:

Per i moduli che operano nella pipeline integrata di IIS 7.0, è necessario registrare i gestori eventi nel metodo Init.

Quando gli eventi dell'applicazione vengono generati, viene chiamato il metodo appropriato nel modulo, il quale può eseguire la logica necessaria, ad esempio il controllo dell'autenticazione o la registrazione delle informazioni sulle richieste. Durante la gestione degli eventi, il modulo ha accesso alla proprietà Context della richiesta corrente. Questo consente di reindirizzare la richiesta a una pagina alternativa, modificare la richiesta o eseguire altre operazioni simili. Se ad esempio il modulo controlla l'autenticazione, potrebbe reindirizzare l'utente a una pagina di accesso o di errore nel caso in cui le credenziali non siano corrette. In caso contrario, quando l'esecuzione del gestore eventi del modulo è terminata, ASP.NET chiama il processo successivo nella pipeline. Potrebbe trattarsi di un altro modulo o del gestore HTTP appropriato (ad esempio un file con estensione aspx) per la richiesta.

Moduli HTTP e file Global.asax

È possibile implementare molte delle funzionalità di un modulo nel file Global.asax dell'applicazione, che consente di rispondere agli eventi dell'applicazione. Tuttavia i moduli, rispetto al file Global.asax, hanno il vantaggio di essere incapsulati e poter essere creati una sola volta per essere utilizzati in numerose applicazioni diverse. Aggiungendoli alla Global Assembly Cache (GAC) e registrandoli nel file Machine.config, è possibile riutilizzarli nelle applicazioni. Per ulteriori informazioni, vedere Global Assembly Cache.

Nota:

In IIS 7.0, la pipeline integrata consente ai moduli gestiti di sottoscrivere le notifiche della pipeline per tutte le richieste, non solo per le richieste per le risorse ASP.NET. I gestori eventi nel file Global.asax vengono richiamati solo per le notifiche durante le richieste per le risorse dell'applicazione. Per i moduli personalizzati in modalità di integrazione è possibile definire l'ambito in modo esplicito per ricevere le notifiche degli eventi solo per le richieste all'applicazione. In caso contrario, i moduli personalizzati ricevono la notifica degli eventi per tutte le richieste all'applicazione. Se l'attributo precondition dell'elemento add della sezione modules è impostato su "managedHandler", l'ambito del modulo viene definito nell'applicazione.

Il vantaggio di utilizzare il file Global.asax sta nel poter gestire gli altri eventi registrati, ad esempio Session_Start e Session_End. Il file Global.asax consente anche di creare istanze di oggetti globali disponibili nell'applicazione.

È necessario utilizzare un modulo quando è necessario creare del codice che dipende dagli eventi dell'applicazione e quando si verificano le condizioni seguenti:

  • Si desidera riutilizzare il modulo nelle altre applicazioni.

  • Si desidera evitare di inserire codice complesso nel file Global.asax.

  • Il modulo si applica a tutte le richieste della pipeline (solo in modalità di integrazione di IIS 7.0).

È necessario aggiungere codice nel file Global.asax quando è necessario creare il codice che dipende dagli eventi dell'applicazione e non è necessario riutilizzarlo nelle applicazioni. È inoltre possibile utilizzare il file Global.asax quando è necessario sottoscrivere eventi che non sono disponibili per i moduli, ad esempio Session_Start.

Creazione di un modulo HTTP

Per scrivere un modulo HTTP, utilizzare la seguente procedura generale:

Per informazioni sullo spostamento di un modulo da un'applicazione in esecuzione in IIS 6.0 o versioni precedenti a un'applicazione in esecuzione in IIS 7.0, vedere Spostamento di un'applicazione ASP.NET da IIS 6.0 a IIS 7.0.

Torna all'inizio

Esempi di codice

Guide rapide

Gestori HTTP e factory

Argomenti relativi alle procedure e alle procedure dettagliate

Procedura: registrare gestori HTTP

Procedura: configurare un'estensione del gestore HTTP in IIS

Procedura dettagliata: creazione di un gestore HTTP sincrono

Procedura: creare un gestore HTTP asincrono

Procedura dettagliata: creazione e registrazione di factory di gestori HTTP

Procedura dettagliata: creazione e registrazione di un modulo HTTP personalizzato

Torna all'inizio

Riferimento alle classi

Nella tabella riportata di seguito vengono elencate le classi server principali per i moduli e i gestori HTTP.

Classe

Descrizione

IHttpModule

Utilizzata per creare un modulo HTTP personalizzato mediante l'implementazione dell'interfaccia e la registrazione del modulo nel file Web.config.

IHttpHandler

Utilizzata per creare un gestore HTTP sincrono personalizzato mediante la creazione di una classe che implementi l'interfaccia.

IHttpAsyncHandler

Utilizzata per creare un gestore HTTP asincrono personalizzato mediante la creazione di una classe che implementi l'interfaccia.

Torna all'inizio

Vedere anche

Concetti

Cenni preliminari sul ciclo di vita delle applicazioni ASP.NET per IIS 5.0 e 6.0

Cenni preliminari sul ciclo di vita delle applicazioni ASP.NET per IIS 7.0

Riferimenti

Torna all'inizio