Información general sobre controladores HTTP y módulos HTTP

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.

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 BeginProcessRequest para 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.

Crear un módulo HTTP

El proceso general para escribir un módulo HTTP es el siguiente:

• Cree una clase que implemente la interfaz IHttpModule.

• Escriba un controlador para el método Init. El método de inicialización debe inicializar el módulo y realizar la suscripción a cualquier evento de aplicación que necesite. Por ejemplo, si desea anexar algún elemento a las respuestas, podría realizar la suscripción al evento EndRequest. Si desea aplicar lógica de autenticación personalizada, podría realizar la suscripción al evento AuthenticateRequest. Para obtener más información sobre 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.

• Escriba código para los eventos a los que se haya suscrito.

• Opcionalmente, implemente el método Dispose si el módulo requiere limpieza.

• Registre el módulo en el archivo Web.config. Para obtener más información, vea Tutorial: Crear y registrar un módulo HTTP personalizado

Para obtener información sobre cómo mover un módulo de una aplicación que se ejecuta en IIS 6.0 o versiones anteriores a una aplicación que se ejecuta en IIS 7.0, vea Mover una aplicación ASP.NET de IIS 6.0 a IIS 7.0.

Volver al principio

Ejemplos de código

Tutoriales rápidos

Controladores y generadores HTTP

Temas "Cómo..." y tutoriales

Cómo: Registrar controladores HTTP

Cómo: Configurar una extensión de controlador HTTP en IIS

Tutorial: Crear un controlador HTTP sincrónico

Cómo: Crear un controlador HTTP asincrónico

Tutorial: Crear y registrar generadores de controladores HTTP

Tutorial: Crear y registrar un módulo HTTP personalizado

Volver al principio

Referencia de clase

En la tabla siguiente se enumeran las clases de servidor clave para los módulos y controladores HTTP.

Volver al principio

Vea también

Conceptos

Información general sobre el ciclo de vida de una aplicación ASP.NET para IIS 5.0 y 6.0

Información general sobre el ciclo de vida de una aplicación ASP.NET para IIS 7.0

Referencia

Volver al principio