Enrutamiento de ASP.

NET
El enrutamiento ASP.NET permite usar direcciones URL que no es necesario asignar a archivos
específicos de un sitio web. Dado que la dirección URL no tiene que asignarse a un archivo, en
una aplicación web puede usar direcciones URL descriptivas de la acción del usuario, y por
tanto, que los usuarios puedan identificar mejor.
En una aplicación ASP.NET que no utiliza enrutamiento, una solicitud entrante de una dirección
URL normalmente se asigna a un archivo físico en el disco como un archivo .aspx. Por ejemplo,
una solicitud de http://server/application/Products.aspx?id=4 se asigna a un archivo
denominado Products.aspx que contiene código y marcado para representar una respuesta al
explorador. La página web utiliza el valor de cadena de consulta de id=4 para determinar qué
tipo de contenido debe mostrarse, pero es probable que el valor tenga poco significado para el
usuario.
En el enrutamiento ASP.NET, se definen modelos de dirección URL que contienen marcadores
de posición para los valores utilizados al administrar solicitudes URL. En tiempo de ejecución, las
partes de la dirección URL que siguen al nombre de aplicación se analizan como valores
discretos, tomando como base un modelo de dirección URL que haya definido. Por ejemplo, en
la solicitud de http://server/application/Products/show/beverages, el analizador del
enrutamiento puede pasar los valores Products, show y beverages a un controlador para la
solicitud. Al contrario, en una solicitud que no administre el enrutamiento de direcciones
URL, /Products/show/beverages se interpretaría como la ruta de acceso de un archivo de la
aplicación.
También puede utilizar los modelos de dirección URL para crear mediante programación
direcciones URL que corresponden a las rutas. Esto permite centralizar la lógica para crear
hipervínculos en la aplicación ASP.NET.

Enrutamiento de ASP.NET frente a reescritura de

direcciones URL
El enrutamiento de ASP.NET es diferente de otros esquemas de reescritura de direcciones URL.
La reescritura de direcciones URL procesa las peticiones entrantes cambiando realmente la
dirección URL antes de enviar la solicitud a la página web. Por ejemplo, una aplicación que
utiliza la reescritura de direcciones URL podría cambiar una dirección URL
de /Products/Widgets/ a /Products.aspx?id=4. Asimismo, la reescritura de direcciones URL
normalmente no tiene una API para crear direcciones URL basadas en sus modelos. En la
reescritura de direcciones URL, si cambia un modelo de dirección URL, deberá actualizar
manualmente todos los hipervínculos que contengan la dirección URL original.
Con el enrutamiento de ASP.NET, la dirección URL no se cambia cuando se controla una
solicitud entrante, porque el enrutamiento puede extraer valores de la dirección URL. Si tiene
que crear una dirección URL, pase los valores del parámetro a un método que genere la
dirección URL para usted. Para cambiar el modelo de dirección URL, cámbielo en una ubicación
y todos los vínculos que cree en la aplicación basada en dicho modelo utilizarán
automáticamente el nuevo modelo.

Definir rutas de dirección URL

Los modelos de dirección URL que se definen se conocen como rutas. En una ruta, se
especifican marcadores de posición que se asignan a valores que se analizan de la solicitud URL.
También se pueden especificar valores constantes que se utilizan para comparar solicitudes URL.
En una ruta, se definen marcadores de posición (denominados parámetros URL) encerrándolos
entre corchetes ( { y } ). El carácter / se interpreta como un delimitador cuando se analiza la
dirección URL. La información de la definición de la ruta que no es un delimitador y que no está
encerrada entre corchetes se trata como un valor constante. Los valores que se extraen entre los
delimitadores se asignan a marcadores de posición.
Puede definir más de un marcador de posición entre los delimitadores, pero deben ir separados
por un valor constante. Por ejemplo, {language}-{country}/{action} es un modelo de ruta
válido. Sin embargo, {language}{country}/{action} no es un modelo válido, porque no hay
ninguna constante o delimitador entre los marcadores de posición. Por consiguiente, el
enrutamiento no puede determinar dónde debe separar el valor del marcador de
posición language del valor del marcador de posición country.
En la tabla siguiente se muestran modelos de ruta válidos y ejemplos de solicitudes URL que
coinciden con los modelos.

Definición de la ruta Ejemplo de dirección URL coincidente

{controlador}/{acción}/{id} /Products/show/beverages

{tabla}/Details.aspx /Products/Details.aspx

blog/{acción}/{entrada} /blog/show/123

{tipo_informe}/{año}/{mes}/{día} /sales/2008/1/5

{configuración regional}/{acción} /en-US/show

{idioma}-{país}/{acción} /en-US/show
Normalmente, se agregan rutas de un método que se llama desde el controlador del
evento Application_Start en el archivo Global.asax. Este enfoque comprueba que las rutas
están disponibles cuando se inicia la aplicación. También permite llamar directamente al
método cuando se realiza una prueba unitaria de la aplicación. Si desea llamar directamente a
un método al realizar una prueba unitaria de la aplicación, el método que registra las rutas debe
ser estático (Shared en Visual Basic) y tener un parámetro RouteCollection.
Añada rutas agregándolas a la propiedad Routes estática de la clase RouteTable. La
propiedad Routes es un objeto RouteCollection que almacena todas las rutas de la aplicación
ASP.NET. En el ejemplo siguiente se muestra el código de un archivo Global.asax que agrega un
objeto Route que define dos parámetros URL denominados action y categoryName.
C#

VB
protected void Application_Start(object sender, EventArgs e)
{
RegisterRoutes(RouteTable.Routes);
}

public static void RegisterRoutes(RouteCollection routes)

{
routes.Add(new Route
(
"Category/{action}/{categoryName}"
, new CategoryRouteHandler()
));
}
Establecer los valores predeterminados de los
parámetros de la ruta
Al definir una ruta, puede asignar un valor predeterminado a un parámetro. El valor
predeterminado se utiliza si un valor de dicho parámetro no está incluido en la dirección URL.
Establezca los valores predeterminados de una ruta asignando un diccionario a la
propiedad Defaults de la clase Route. En el ejemplo siguiente se muestra una ruta con valores
predeterminados.
C#

VB
void Application_Start(object sender, EventArgs e)
{
RegisterRoutes(RouteTable.Routes);
}

public static void RegisterRoutes(RouteCollection routes)

{
routes.Add(new Route
(
"Category/{action}/{categoryName}"
new CategoryRouteHandler()
)
{
Defaults = new RouteValueDictionary
{{"categoryName", "food"}, {"action", "show"}}
}
);
}
Cuando el enrutamiento de ASP.NET controla una solicitud URL, la definición de ruta mostrada
en el ejemplo (con los valores predeterminados
de food para categoryName y show para action) genera los resultados que se enumeran en la
tabla siguiente.

dirección URL Valores de parámetros

/Category action = "mostrar" (valor predeterminado)

categoryName = "comida" (valor predeterminado)

/Category/add action = "agregar"

categoryName = "comida" (valor predeterminado)

/Category/add/beverages action = "agregar"

categoryName= "bebidas"

Administrar un número variable de segmentos

A veces tiene que controlar solicitudes URL que contienen un número variable de segmentos de
dirección URL. Al definir una ruta, puede especificar que el último parámetro coincida con el
resto de la dirección URL marcando el parámetro con un asterisco (*. Esto se conoce como un
parámetro comodín. Una ruta con un parámetro comodín también coincidirá con las direcciones
URL que no contienen ningún valor para el último parámetro. En el ejemplo siguiente se
muestra un modelo de ruta que coincide con un número de segmentos desconocido.
query/{queryname}/{*queryvalues}
Cuando el enrutamiento de ASP.NET controla una solicitud URL, la definición de la ruta
mostrada en el ejemplo genera los resultados que se enumeran en la tabla siguiente.

dirección URL Valores de parámetros

/query/select/bikes/onsale queryname = "select"

queryvalues = "bikes/onsale"

/query/select/bikes queryname = "select"

queryvalues = "bikes"

/query/select queryname = "select"

queryvalues = Cadena vacía

Agregar restricciones a las rutas

Además de comparar una solicitud URL con una definición de ruta por el número de parámetros
de la dirección URL, puede especificar que los valores de los parámetros cumplan ciertas
restricciones. Si una dirección URL contiene valores que están fuera de las restricciones de una
ruta, esa ruta no se utiliza para administrar la solicitud. Agregue restricciones para asegurarse de
que los parámetros URL contienen valores que funcionarán en la aplicación.
Las restricciones se definen utilizando expresiones regulares u objetos que implementan la
interfaz IRouteConstraint. Al agregar la definición de la ruta a la colección Routes, agregue
restricciones creando un objeto RouteValueDictionary que contenga la prueba de
comprobación. A continuación, asigne este objeto a la propiedad Constraints . La clave del
diccionario identifica el parámetro al que se aplica la restricción. El valor del diccionario puede
ser o una cadena que representa una expresión regular o un objeto que implementa la
interfaz IRouteConstraint.
Si proporciona una cadena, el enrutamiento trata la cadena como una expresión regular y
comprueba si el valor del parámetro es válido llamando al método IsMatch de la clase Regex. La
expresión regular siempre se trata sin distinción entre mayúsculas y minúsculas. Para obtener
más información, vea Expresiones regulares de .NET Framework.
Si proporciona un objeto IRouteConstraint, el enrutamiento de ASP.NET comprueba si el valor
del parámetro es válido llamando al método Match del objeto IRouteConstraint. El
método Match devuelve un valor booleano que indica si el valor de parámetro es válido.

Información general sobre

controladores HTTP y
módulos HTTP
Visual Studio 2010

Otras versiones
Actualización: noviembre 2007
Un controlador HTTP de ASP.NET es el proceso (con frecuencia llamado el "extremo") que se
ejecuta como respuesta a una solicitud realizada a una aplicación Web ASP.NET. El controlador
más común es el de la página ASP.NET que procesa archivos .aspx. Cuando los usuarios solicitan
un archivo .aspx, la página procesa la solicitud a través del controlador de páginas. Puede crear
sus propios controladores HTTP que representen el resultado personalizado en el explorador.
Un módulo HTTP es un ensamblado al que se llama en cada solicitud realizada a la aplicación.
Los módulos HTTP se llaman como parte de la canalización de solicitudes de ASP.NET y tienen
acceso a los eventos de ciclo de vida a lo largo de la solicitud. Los módulos HTTP permiten
examinar las solicitudes de entrada y de salida y realizar acciones basadas en la solicitud.
Este tema contiene:
 Escenarios
 Características de controladores y módulos HTTP
 Información general
 Ejemplos de código
 Referencia de clase

Escenarios
Entre los usos habituales de los controladores HTTP personalizados se incluyen los siguientes:
 Fuentes RSS Para crear una fuente RSS para un sitio web, puede crear un controlador
que emita XML con formato RSS. A continuación, puede enlazar una extensión de
nombre de archivo como .rss al controlador personalizado. Cuando los usuarios envían
una solicitud al sitio que finaliza en .rss, ASP.NET llama al controlador para procesarla.
 Servidor de imágenes Si desea que una aplicación web sirva imágenes en diferentes
tamaños, puede escribir un controlador personalizado para cambiar el tamaño de las
imágenes y después enviarlas al usuario como respuesta del controlador.
Entre los usos habituales de los módulos HTTP se incluyen los siguientes:
 Seguridad Dado que se pueden examinar las solicitudes entrantes, un módulo HTTP
puede realizar una autenticación personalizada u otras comprobaciones de seguridad
antes de que se llame a la página, al servicio web XML o al controlador solicitado. En el
modo integrado de Internet Information Services (IIS) 7.0, puede extender la
autenticación de formularios a todos los tipos de contenido de una aplicación.
 Estadística y registro Dado que en cada solicitud se llama a módulos HTTP, puede
recopilar estadísticas e información de registro sobre las solicitudes en un módulo
centralizado, en lugar de hacerlo en páginas individuales.
 Encabezados o pies personalizados Dado que es posible modificar la respuesta de
salida, se puede insertar contenido, como información de encabezado personalizada, en
cada respuesta de página o servicio web XML.
Volver al principio

Características
Entre las características de controladores y módulos HTTP se incluyen las siguientes:
 Las interfaces IHttpHandler y IHttpModule son el punto inicial para desarrollar
controladores y módulos.
 La interfaz IHttpAsyncHandler es el punto inicial para desarrollar controladores
asincrónicos.
 El código fuente de controladores y módulos personalizados se puede incluir en la
carpeta App_Code de una aplicación o bien se puede compilar e incluir en la carpeta Bin
de una aplicación.
 Los controladores y módulos desarrollados para el uso en IIS 6.0 se pueden utilizar en
IIS 7.0 con pocos cambios o sin cambio alguno. Para obtener más información,
vea Mover una aplicación ASP.NET de IIS 6.0 a IIS 7.0.
  Los módulos se pueden suscribir a diferentes notificaciones de canalización de
solicitudes. Los módulos pueden recibir notificación de eventos del
objeto HttpApplication.
 En IIS 7.0, la canalización de solicitudes se integra con la canalización de solicitudes del
servidor web. Los módulos HTTP se pueden utilizar para cualquier solicitud al servidor
web, no sólo para solicitudes ASP.NET.
Volver al principio

Información general
Controladores HTTP
Un controlador HTTP de ASP.NET es el proceso que se ejecuta como respuesta a una solicitud
realizada a una aplicación web ASP.NET. El controlador más común es el de la página ASP.NET
que procesa archivos .aspx. Cuando los usuarios solicitan un archivo .aspx, el controlador de
páginas procesa la solicitud.
El controlador de páginas de ASP.NET sólo es un tipo de controlador. ASP.NET incluye otros
controladores integrados, como el controlador de servicios web para archivos .asmx.
Controladores HTTP integrados en ASP.NET
ASP.NET asigna solicitudes HTTP a controladores HTTP en función de la extensión del nombre
de un archivo. Cada controlador HTTP puede procesar direcciones URL HTTP individuales o
grupos de extensiones URL de una aplicación. ASP.NET incluye varios controladores HTTP
integrados, como se muestra en la tabla siguiente.

Controlador Descripción

Controlador de Controlador HTTP predeterminado para todas las páginas

páginas ASP.NET ASP.NET.
(*.aspx)

Controlador de Controlador HTTP predeterminado para las páginas de

servicios Web servicios web creadas como archivos .asmx en ASP.NET.
(*.asmx)

Controlador web El controlador HTTP predeterminado para todos los

genérico (* .ashx) controladores web que no tienen ninguna interfaz de usuario y
que incluyen la directiva @ WebHandler.

Controlador de Controlador que muestra la información de seguimiento de la

seguimiento página actual. Para obtener información detallada, vea Cómo:
(trace.axd) Ver información de seguimiento de ASP.NET con el visor de
seguimiento.
Crear un controlador HTTP personalizado
Para crear un controlador HTTP personalizado, crea una clase que implementa la
interfaz IHttpHandler para crear un controlador sincrónico. También puede
implementar IHttpAsyncHandler para crear un controlador asincrónico. Las dos interfaces del
controlador requieren que implemente la propiedad IsReusable y el método ProcessRequest. La
propiedad IsReusable especifica si el objeto IHttpHandlerFactory (el objeto que realmente llama
al controlador adecuado) puede colocar el controlador en un grupo y reutilizarlo para aumentar
el rendimiento. Si el controlador no se puede agrupar, el generador debe crear una nueva
instancia del controlador cada vez que se necesite.
El método ProcessRequest es responsable de procesar las solicitudes HTTP individuales. En este
método, escribe el código que genera el resultado para el controlador.
Los controladores HTTP tienen acceso al contexto de la aplicación. Esto incluye la identidad del
usuario que realiza la solicitud (si se conoce), el estado de la aplicación e información de la
sesión. Cuando se solicita un controlador HTTP, ASP.NET llama al método ProcessRequest del
controlador adecuado. El código que escribe en el método ProcessRequest del controlador crea
una respuesta, que se devuelve al explorador que realizó la solicitud.
Asignar una extensión de nombre de archivo
Al crear un archivo de clase como controlador HTTP, el controlador puede responder a cualquier
extensión de nombre de archivo que aún no esté asignada en IIS ni en ASP.NET. Por ejemplo, si
crea un controlador HTTP para generar una fuente RSS, puede asignar el controlador a la
extensión de nombre de archivo .rss. Para que ASP.NET sepa qué controlador debe utilizar para
la extensión de nombre de archivo personalizada, en IIS debe asignar la extensión a ASP.NET. A
continuación, en la aplicación, debe asignar la extensión al controlador personalizado.
De forma predeterminada, ASP.NET asigna la extensión de nombre de archivo .ashx a un
controlador HTTP. Si agrega la directiva @ WebHandler a un archivo de clase, ASP.NET asigna
automáticamente la extensión de nombre de archivo .ashx al controlador HTTP predeterminado.
Esto es similar a la manera en que ASP.NET asigna la extensión de nombre de archivo .aspx al
controlador de páginas ASP.NET cuando se utiliza la directiva @ Page. Por tanto, si crea una
clase de controladores HTTP con la extensión de nombre de archivo .ashx, el controlador se
registra automáticamente con IIS y ASP.NET.
Si desea crear una extensión de nombre de archivo personalizada para un controlador, debe
registrar explícitamente la extensión con IIS y ASP.NET. Si no se utiliza la extensión de nombre
de archivo .ashx, el controlador se puede volver a utilizar en diferentes asignaciones de
extensión. Por ejemplo, en una aplicación el controlador personalizado podría responder a
solicitudes que finalizan en .rss. En otra aplicación, podría responder a las solicitudes que
finalizan en .feed. Otro ejemplo podría ser que el controlador estuviera asignado a ambas
extensiones de nombre de archivo en la misma aplicación, pero crease respuestas diferentes
basándose en la extensión.
El proceso para registrar la extensión de nombre de archivo personalizada de un controlador es
diferente en IIS 7.0 y en versiones anteriores de IIS. Para obtener más información, vea Cómo:
Registrar controladores HTTP y Cómo: Configurar una extensión de controlador HTTP en IIS.
Controladores HTTP asincrónicos y sincrónicos
Un controlador HTTP puede ser sincrónico o asincrónico. Un controlador sincrónico no vuelve
hasta que termina de procesar la solicitud HTTP para la que se le llamó. Un controlador
asincrónico ejecuta un proceso independientemente del envío de una respuesta al usuario. Los
controladores asincrónicos son útiles cuando se debe iniciar un proceso de aplicación que
puede ser largo y el usuario no debe esperar hasta que éste finalice antes de recibir una
respuesta del servidor.
Los controladores HTTP asincrónicos permiten iniciar un proceso externo, como una llamada a
métodos en un servidor remoto. El controlador puede continuar el procesamiento sin esperar
hasta que finalice el proceso externo. Mientras se procesa un controlador HTTP asincrónico,
ASP.NET coloca el subproceso que normalmente se utilizaría para el proceso externo de vuelta
en el grupo de subprocesos hasta que el controlador recibe una devolución de llamada del
proceso externo. Esto puede evitar el bloqueo de los subprocesos y mejorar el rendimiento, ya
que sólo es posible ejecutar a la vez un número limitado de subprocesos. Si varios usuarios
solicitan controladores HTTP sincrónicos que dependen de procesos externos, el sistema
operativo puede quedarse sin subprocesos porque muchos estarán bloqueados y esperando un
proceso externo.
Al crear un controlador asincrónico, debe implementar la interfaz IHttpAsyncHandler. También
debe implementar el método BeginProcessRequestpara iniciar una llamada asincrónica que
procese las solicitudes HTTP individuales. Además, debe implementar el
método EndProcessRequest para ejecutar código de limpieza cuando finalice el proceso.
Clases IHttpHandlerFactory personalizadas
La clase IHttpHandlerFactory recibe solicitudes y es responsable de reenviar una solicitud al
controlador HTTP adecuado. Puede crear un generador del controlador HTTP personalizado
creando una clase que implementa la interfaz IHttpHandlerFactory. Los generadores de
controladores personalizados pueden permitir un control más preciso sobre la forma en que se
procesan las solicitudes HTTP, mediante la creación de diferentes controladores basados en
condiciones en tiempo de ejecución. Por ejemplo, con un generador de controladores HTTP
personalizado es posible crear una instancia de un controlador HTTP para un tipo de archivo si
el método de solicitudes HTTP es PUT y otro distinto si el método es GET.
Para registrar una extensión personalizada para un generador de controladores, siga los pasos
para registrar una extensión personalizada para un controlador. Para obtener un ejemplo sobre
la creación y el registro de un generador de controladores, vea Tutorial: Crear y registrar
generadores de controladores HTTP.
Módulos HTTP
Un módulo HTTP es un ensamblado al que se llama en cada solicitud realizada a la aplicación.
Los módulos HTTP se llaman como parte de la canalización de solicitudes y tienen acceso a los
eventos de ciclo de vida a lo largo de la solicitud. Los módulos HTTP permiten por tanto
examinar las solicitudes de entrada y realizar acciones basadas en la solicitud. También permiten
examinar la respuesta de salida y modificarla.
En IIS 6.0, la canalización de solicitudes de ASP.NET es independiente de la canalización de
solicitudes del servidor web. En IIS 7.0, la canalización de solicitudes de ASP.NET y la
canalización de solicitudes del servidor web se pueden integrar en una canalización de
solicitudes común. En IIS 7.0, esto se conoce como modo integrado. La canalización unificada
presenta varias ventajas para los programadores de ASP.NET. Por ejemplo, permite que los
módulos de código administrado reciban notificaciones de la canalización para todas las
solicitudes, aun cuando las solicitudes no correspondan a recursos de ASP.NET. Sin embargo, si
lo desea, puede ejecutar IIS 7.0 en modo clásico, que emula a ASP.NET ejecutado en IIS 6.0. Para
obtener más información, vea Información general sobre el ciclo de vida de una aplicación
ASP.NET para IIS 7.0.
Los módulos HTTP de ASP.NET son similares a los filtros ISAPI ya que se invocan para todas las
solicitudes. Sin embargo, se escriben en el código administrado y se integran totalmente con el
ciclo de vida de una aplicación ASP.NET. Puede incluir código fuente de módulo personalizado
en la carpeta App_Code de la aplicación o bien puede incluir los módulos personalizados
compilados como ensamblados en la carpeta Bin de una aplicación.
ASP.NET utiliza módulos para implementar varias características de aplicación, como la
autenticación de formularios, el almacenamiento en caché, el estado de sesión o los servicios de
script de cliente. En cada caso, cuando se habilitan dichos servicios, al módulo se le llama como
parte de una solicitud y realiza tareas que están fuera del ámbito de cualquier solicitud de una
sola página. Los módulos pueden utilizar eventos de aplicación y pueden provocar eventos que
se pueden controlar en el archivo Global.asax. Para obtener más información acerca de los
eventos de aplicación, vea Información general sobre el ciclo de vida de una aplicación ASP.NET
para IIS 5.0 y 6.0 y Información general sobre el ciclo de vida de una aplicación ASP.NET para IIS
7.0.

Nota:
 Los módulos HTTP difieren de los controladores HTTP. Un controlador HTTP
devuelve una respuesta a una solicitud que se identifica mediante una extensión de
nombre de archivo o una familia de extensiones de nombre de archivo. Los módulos
HTTP, sin embargo, se invocan para todas las solicitudes y respuestas. Se suscriben
a las notificaciones de eventos de la canalización de solicitudes y permiten ejecutar
código en controladores de eventos registrados. Las tareas para las que se utiliza un
módulo son generales para una aplicación y para todas las solicitudes de los recursos
incluidos en la aplicación.

Cómo funcionan los módulos HTTP

Los módulos se deben registrar para recibir las notificaciones de la canalización de solicitudes.
La manera más habitual de registrar un módulo HTTP consiste en utilizar el archivo Web.config
de la aplicación. En IIS 7.0, la canalización de solicitudes unificada también permite registrar un
módulo de otras maneras, por ejemplo a través de IIS Manager o a través de la herramienta de
la línea de comandos Appcmd.exe. Para obtener más información, vea Configuring Handler
Mappings in IIS 7.0 y Start Appcmd.exe.
Cuando ASP.NET crea una instancia de la clase HttpApplication que representa la aplicación, se
crean instancias de cualquier módulo que se haya registrado. Cuando se crea un módulo, se
llama a su método Init y el módulo se inicializa por sí solo. Para obtener más información,
vea Información general sobre el ciclo de vida de una aplicación ASP.NET para IIS 5.0 y
6.0 y Información general sobre el ciclo de vida de una aplicación ASP.NET para IIS 7.0.
En el método Init de un módulo se permite la suscripción a varios eventos de aplicación,
como BeginRequest o EndRequest, mediante el enlace de los eventos a los métodos del
módulo.

Nota:

En los módulos que funcionan en la canalización integrada de IIS 7.0, debería

registrar los controladores de eventos en el método Init.
Cuando se provocan eventos de aplicación, se llama al método adecuado del módulo. El
método puede realizar la lógica necesaria, como comprobar la autenticación o registrar
información de la solicitud. Durante el control de eventos, el módulo tiene acceso a la
propiedad Context de la solicitud actual. Esto permite redirigir la solicitud a una página
alternativa, modificar la solicitud o realizar cualquier otra manipulación de la solicitud. Por
ejemplo, si el módulo comprueba la autenticación, podría redirigir a una página de inicio de
sesión o de error si las credenciales no son correctas. De lo contrario, cuando el controlador de
eventos del módulo ha terminado de ejecutarse, ASP.NET llama al proceso siguiente en la
canalización. Puede tratarse de otro módulo o del controlador HTTP adecuado (como un archivo
.aspx) para la solicitud.
Módulos HTTP comparados con archivos Global.asax
Puede implementar muchas de las funciones de un módulo en el archivo Global.asax de la
aplicación, lo que permite responder a los eventos de aplicación. Sin embargo, los módulos
tienen ventaja sobre el archivo Global.asax ya que están encapsulados y se pueden crear una vez
y utilizarse en muchas aplicaciones diferentes. Si se agregan a la caché de ensamblados global y
se registran en el archivo Machine.config, puede reutilizarlos en distintas aplicaciones. Para
obtener más información, vea Caché de ensamblados global.
 Nota:

En IIS 7.0, la canalización integrada permite que los módulos administrados se

suscriban a las notificaciones de la canalización de todas las solicitudes, no sólo de
solicitudes para recursos de ASP.NET. Los controladores de eventos del archivo
Global.asax sólo se invocan para las notificaciones durante solicitudes para los
recursos de la aplicación. En los módulos personalizados en modo integrado el
ámbito se puede establecer de forma explícita para recibir únicamente las
notificaciones de evento correspondientes a solicitudes para la aplicación. De lo
contrario, los módulos personalizados reciben la notificación de eventos para todas
las solicitudes a la aplicación. Si el atributo precondition del elemento add de la
sección modules se establece en "managedHandler", el ámbito del módulo se limita
a la aplicación.
La ventaja de utilizar el archivo Global.asax es que puede administrar otros eventos registrados
como Session_Start y Session_End. Además, el archivo Global.asax permite crear instancias de
objetos globales que están disponibles en toda la aplicación.
Debería utilizar un módulo siempre que deba crear código que dependa de eventos de
aplicación y cuando se cumplan las condiciones siguientes:
 Desea volver a utilizar el módulo en otras aplicaciones.
 Desea evitar incluir código complejo en el archivo Global.asax.
 El módulo se aplica a todas las solicitudes de la canalización (sólo en modo integrado
de IIS 7.0).
Debe agregar código en el archivo Global.asax cada vez que sea necesario crear código que
dependa de eventos de aplicación y no tenga que volver a utilizarse en diferentes aplicaciones.
También puede utilizar el archivo Global.asax si es necesario realizar la suscripción a eventos
que no están disponibles para los módulos, como Session_Start.