Compartir a través de


Integración de ASP.NET con IIS 7

de Mike Volodarsky

Introducción

Desde su lanzamiento, ASP.NET ha sido la plataforma más utilizada para desarrollar aplicaciones web en la plataforma Windows/IIS. ASP.NET 2.0 llevó el desarrollo de aplicaciones web a un nuevo nivel, lo que permite a los desarrolladores crear aplicaciones más eficaces más rápidamente que nunca.

Tanto IIS 7 como las versiones posteriores llevan ASP.NET al siguiente nivel, ya que integran el modelo de extensibilidad del runtime de ASP.NET en el servidor principal, lo que permite a los desarrolladores ampliar completamente el servidor de IIS con la gran cantidad de funciones que ofrecen ASP.NET 2.0 y .NET Framework, en lugar de usar las API de C++ de IIS, que tienen menos posibilidades. Las aplicaciones de ASP.NET existentes también se benefician inmediatamente de una mayor integración, ya que les permite usar características de ASP.NET existentes, como la autenticación mediante formularios, los roles y almacenamiento de la salida en la caché, sea cual sea el contenido.

Aunque IIS ofrece la integración mejorada de ASP.NET de forma predeterminada, existe la posibilidad de elegir: IIS admite tanto el modo de integración de ASP.NET nuevo como el antiguo, y se pueden utilizar conjuntamente en el mismo servidor.

En este artículo se describen las mejoras que aporta el modo de integración ASP.NET, la arquitectura de los dos modos y se indica cómo seleccionar y configurar los modos de integración para las aplicaciones de ASP.NET.

Mejoras de ASP.NET en IIS 7 y en las versiones superiores

La mejor integración de ASP.NET en IIS no solo mejora las aplicaciones existentes, sino que también permite que las nuevas aplicaciones aprovechen las características de ASP.NET como se indica a continuación:

  • Los servicios de ASP.NET se pueden usar para todos los tipos de contenido. Anteriormente, funcionalidades de ASP.NET como autenticación mediante formularios, los roles, la autorización de direcciones URL y almacenamiento en caché de la salida solo estaban disponibles para los tipos de contenido de ASP.NET como las páginas ASPX. Los archivos estáticos, las páginas ASP y otros tipos de contenido no se podían beneficiar de estos servicios.

En IIS, todos los servicios de ASP.NET se proporcionan de forma uniforme a todo el contenido. Por ejemplo, todo el contenido web, incluidas las imágenes y las páginas ASP, se puede proteger con la solución de control de acceso de ASP.NET 2.0 existente, que se basa en la autenticación mediante formularios, la pertenencia y los controles de inicio de sesión de ASP.NET.

  • Amplíe IIS al máximo con ASP.NET. Dadas las limitaciones del runtime de ASP.NET las versiones anteriores de IIS a menudo requerían que la extensibilidad del servidor se desarrollara mediante el filtro ISAPI nativo o el modo de extensibilidad de extensiones.

IIS permite que los módulos de ASP.NET se conecten directamente a la canalización del servidor, con la misma fidelidad en tiempo de ejecución que los módulos desarrollados con la API de servidor nativa (C++). Los módulos de ASP.NET pueden ejecutarse en todas las fases del tiempo de ejecución de la canalización de procesamiento de solicitudes y en cualquier orden, con respecto a los módulos nativos. La API de ASP.NET también se expande para permitir un mayor control sobre el procesamiento de solicitudes que antes.

  • Runtime de servidor unificado. La mayor integración de ASP.NET también unifica muchas de las características entre IIS y ASP.NET.

IIS proporciona una configuración unificada para los módulos y controladores de IIS y ASP.NET. Muchas otras características, entre las que se incluyen los errores personalizados y el seguimiento, se han unificado para permitir una mejor administración y un diseño de aplicaciones cohesivo.

Arquitectura de la integración de ASP.NET

Tanto en IIS 6.0 como en las versiones anteriores, ASP.NET se implementaba como una extensión ISAPI de IIS.

En estas versiones anteriores, IIS procesaba una solicitud a un tipo de contenido de ASP.NET y, después, reenviaba esa solicitud al archivo DLL de ISAPI de ASP.NET, que hospedaba la canalización de solicitudes ASP.NET y el marco de la página. Las solicitudes que se enviaban a contenido que no fuera de ASP.NET, como las páginas ASP o los archivos estáticos, las procesaba IIS, u otras extensiones de ISAPI y ASP.NET no las veía.

La principal limitación de este modelo era que los servicios que proporcionaban los módulos´de ASP.NET y el código de aplicaciones de ASP.NET personalizado no estaban disponibles para solicitudes que no sean de ASP.NET. Además, los módulos de ASP.NET módulos no podían afectar a determinadas partes del procesamiento de solicitudes de IIS que se produjeron antes y después de la ruta de acceso de ejecución de ASP.NET.

Diagram that shows I I S 6 and A S P dot NET pipelines.

Figura 1: Canalizaciones de IIS 6.0 y de ASP.NET

En IIS, la canalización de procesamientos de solicitudes de ASP.NET superpone directamente la canalización de IIS, lo que básicamente proporciona un contenedor sobre él, en lugar de conectarlo a ella.

IIS procesa las solicitudes de cualquier tipo de contenido que llegan, con módulos de IIS nativos y módulos de ASP.NET que proporcionan procesamiento de solicitudes en todas las fases, lo que permite que los servicios que proporcionan los módulos de ASP.NET, como la autenticación de formularios o la caché de salida, se usen para solicitudes a páginas ASP, páginas PHP, archivos estáticos, etc.

La capacidad de conectar directamente a la canalización del servidor permite que los módulos de ASP.NET reemplacen, ejecuten antes o ejecuten después de cualquier funcionalidad de IIS, lo que permite, por ejemplo, un módulo de autenticación básica de ASP.NET personalizado que se escribe para usar el servicio de suscripción y la base de datos de usuario de SQL Server para reemplazar la característica de autenticación básica de IIS integrada que solo funciona con cuentas de Windows.

Además, las API de ASP.NET expandidas usan la integración directa para habilitar más tareas de procesamiento de solicitudes. Por ejemplo, los módulos de ASP.NET pueden modificar los encabezados de la solicitud antes de que otros componentes la procesen y para hacerlo insertan un encabezado de Accept-Language antes de que se ejecuten las aplicaciones ASP, lo que obliga a que el contenido localizado se devuelva al cliente en función de las preferencias del usuario.

Diagram that shows I I S 7 and above integrated mode.

Figura 2: Modo Integrado de IIS 7 y las versiones posteriores

Debido a la integración del runtime, tanto IIS como ASP.NET pueden usar la misma configuración para habilitar y solicitar módulos de servidor, así como para configurar asignaciones de controladores. Otras funcionalidades unificadas incluyen el seguimiento, los errores personalizados y el almacenamiento en caché de la salida.

Compatibilidad

En particular, la arquitectura mantiene la arquitectura del runtime y las API de ASP.NET, lo que permite que las aplicaciones y los servicios de ASP.NET existentes funcionen tras la instalación. Con algunas modificaciones, las aplicaciones y los servicios y las aplicaciones de ASP.NET pueden aprovechar las nuevas funcionalidades de ASP.NET.

De igual forma, los desarrolladores pueden seguir escribiendo nuevas aplicaciones en las conocidas API de ASP.NET mientras disfrutan de las ventajas de la integración del runtime.

IIS sigue proporcionando el modo Clásico de ASP.NET para las aplicaciones de ASP.NET que tienen requisitos de compatibilidad específicos que el modo Integrado no permite cumplir. Los administradores pueden seleccionar el modo de integración deseado en cada grupo de aplicaciones, lo que permite a las aplicaciones que usan los dos modos de ASP.NET, el nuevo y el Clásico, funcionen en paralelo en el mismo servidor.

Migración de aplicaciones de ASP.NET al modo Integrado de IIS 7 y de las versiones posteriores

En IIS, ASP.NET está configurado para funcionar de forma predeterminada en el nuevo modo Integrado, lo que permite que la aplicación aproveche las mejoras del modo Integrado con mínimas modificaciones.

Debido a la unificación de la configuración, es posible que algunas aplicaciones requieran una migración para funcionar correctamente en modo Integrado. De forma predeterminada, el servidor ofrece ayuda con la migración. Detecta aquellas aplicaciones que requieren migración y devuelve un mensaje de error en el que se solicita la migración de la aplicación.

La siguiente configuración provoca el error de migración:

  1. El archivo Web.config de la aplicación define la configuración de < httpModules>.
    La aplicación carga nuevos módulos de ASP.NET o quita los existentes.
    En el modo Integrado, los módulos de ASP.NET se especifican con módulos nativos en la sección de configuración de <system.webServer>/<modules> unificada.
    Para que los módulos de ASP.NET que se especifican en la sección de configuración de <system.web>/<httpModules> surtan efecto se deben mover a la nueva sección de configuración. Posteriormente, se deben agregar nuevos módulos de ASP.NET directamente a la sección <modules> unificada.
  2. El archivo Web.config de la aplicación define la configuración de <httpHandlers>.
    La aplicación usa asignaciones de controladores personalizadas para algunos tipos de contenido.
    En el modo Integrado, para que las asignaciones de controladores de ASP.NET surtan efecto se deben especificar en la sección de configuración <unified system.webServer>/<handlers>. Posteriormente, se deben agregar nuevas asignaciones de controladores de ASP.NET directamente a la sección <handlers> unificada.
    En esta sección se reemplaza tanto la configuración <httpHandlers> de ASP.NET como la configuración de los mapas de scripts de IIS, que anteriormente tenían que configurarse para configurar cualquier asignación de controladores de ASP.NET.
  3. El archivo Web.config de la aplicación define la configuración <identity impersonate="true" />.
    La aplicación suplanta las credenciales de cliente, lo que es más habitual con las aplicaciones de intranet. En el modo Integrado, la suplantación de cliente no está disponible en algunas de las primeras fases de procesamiento de solicitudes. En la mayoría de los casos, esto no supone ningún problema y puede desactivar el error de migración. De lo contrario, debe configurar esta aplicación para que se ejecute mediante el modo Clásico de ASP.NET.

Cuando se genera el error de migración, habitualmente puede migrar la configuración de la aplicación (lo que se recomendada en los casos 1 y 2 anteriores), o bien mover la aplicación para que use el modo Clásico de ASP.NET (en el caso 3).

Migración de la configuración de la aplicación

IIS utiliza la herramienta de línea de comandos AppCmd.exe para realizar la migración. El mensaje de error de migración contiene el comando que se ejecuta en la ventana de la línea de comandos, que debe ejecutar con derechos de usuario de administrador, para migrar al instante la aplicación al modo Integrado.

Este es el formato básico del comando de migración:

%windir%\system32\inetsrv\APPCMD.EXE migrate config <Application Path>

Donde <Ruta de acceso> es la ruta de acceso virtual de la aplicación que contiene el nombre del sitio, como "Sitio web predeterminado/app1".

Una vez completada la migración, la aplicación se ejecutará en los modos Integrado y Clásico sin problemas.

Nota:

Si cambia la configuración después de la migración, el servidor no le pedirá que vuelva a realizarla. Tras la migración inicial, debe asegurarse de que la configuración permanece sincronizada entre los dos modos. Para volver a migrar manualmente la aplicación, utilice la herramienta de línea de comandos AppCmd.exe.

Volver al modo Integración de ASP.NET

Si prefiere volver al modo Clásico de ASP.NET, mueva la aplicación a un grupo de aplicaciones configurado para ejecutarse en modo Clásico. Otras aplicaciones siguen ejecutándose en el nuevo modo Integrado en paralelo con la aplicación en modo Clásico.

Para más información sobre cómo mover una aplicación al modo Clásico de ASP.NET, consulte Cambio de modos de ASP.NET para una aplicación.

Deshabilitación del mensaje de error de migración

Si ha migrado manualmente la configuración o desea permanecer en modo Integrado sin migrar la configuración (no se recomienda), puede deshabilitar el mensaje de error de migración agregando lo siguiente al archivo Web.config de la aplicación:

<system.webServer> 
    <validation validateIntegratedModeConfiguration="false" />    
</system.webServer>

Nota:

El servidor deshabilita automáticamente el mensaje de error después de migrar la configuración con la herramienta de línea de comandos AppCmd.exe.

Si deshabilita manualmente el mensaje de error de migración, debe asegurarse de que la aplicación funciona correctamente en modo Integrado, ya que el servidor no proporcionará ninguna advertencia sobre la configuración no admitida.

Cambio de los modos de ASP.NET para una aplicación

Si la aplicación no funciona correctamente en modo Integrado de ASP.NET, puede moverla al modo Clásico de ASP.NET. Para ello, debe cambiarla de grupo de aplicaciones. Cada grupo de aplicaciones está configurado individualmente para usar el modo de integración de ASP.NET deseado, lo que le permite ejecutar grupos de aplicaciones que usan diferentes modos de integración de ASP.NET en paralelo en el mismo servidor.

Para cambiar el modo de integración de ASP.NET para una aplicación:

  1. Busque o cree un grupo de aplicaciones configurado para usar el modo deseado.
    De forma predeterminada, todos los grupos de aplicaciones nuevos se ejecutan en modo Integrado.
    La configuración de ASP.NET proporciona un grupo de aplicaciones denominado "AppPool de .NET clásico" que se ejecuta en el modo Integración de ASP.NET clásico. Puede usar este grupo de aplicaciones para las aplicaciones que no deben ejecutarse en modo Integrado.
    También puede cambiar el modo de ASP.NET del grupo de aplicaciones existente mediante la herramienta de Administración de IIS o la herramienta de línea de comandos AppCmd.exe, o bien mediante la edición manual de la configuración del grupo de aplicaciones.
  2. Establezca que la aplicación use ese grupo de aplicaciones.
    Cada aplicación está configurada para usar un grupo de aplicaciones determinado. De forma predeterminada, todas las aplicaciones usan el grupo de aplicaciones predeterminado denominado "DefaultAppPool", que se ejecuta en modo Integrado.
    Para cambiar el grupo de aplicaciones de una aplicación, utilice herramienta de Administración de IIS o la herramienta de línea de comandos AppCmd.exe, o bien mediante la edición manual de la configuración del grupo de aplicaciones.

Selección de la versión de ASP.NET de una aplicación

Históricamente, IIS ha admitido varias versiones de ASP.NET/CLR en paralelo. Por ejemplo, IIS permite que el mismo servidor ejecute aplicaciones de ASP.NET mediante .NET Framework v1.1 y v2.0. Para ofrecer esta compatibilidad se asigna una versión correspondiente de ASPNET_isapi.dll para que sirva las solicitudes de contenido de ASP.NET mediante la configuración de mapas de scripts de IIS.

Por ejemplo, puede usar la siguiente configuración de mapa de scripts para habilitar la compatibilidad en paralelo:

  1. Aplicación ASP.NET v1.1 en /app1:
    *.aspx -> d:\WINDOWS\Microsoft.NET\Framework\v1.1.4322\aspnet_isapi.dll
  2. Aplicación ASP.NET v2.0 en /app2:
    *.aspx -> d:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\aspnet_isapi.dll

Cuando la aplicación recibe una solicitud *.aspx, IIS carga el archivo aspnet_isapi.dll especificado, que carga la versión de CLR correcta en el proceso de trabajo y procesa la solicitud.

ASP.NET también proporciona las siguientes maneras de configurar mapas de scripts en paralelo:

  1. Extensión MMC de ASP.NET. Cuando se elige la versión de ASP.NET que se va a usar, la extensión configura automáticamente los mapas de scripts de la aplicación para que apunten a la versión correcta de aspnet_isapi.dll.
  2. ASP.NET aspnet_regiis.exe. Use las opciones –i y –r para instalar los mapas de scripts que apuntan a la versión de ASP.NET correspondiente.

Desafortunadamente, dada la limitación de la capacidad para cargar sólo una versión de CLR en un único proceso de trabajo, debe asegurarse de que dos aplicaciones que utilicen diferentes versiones de ASP.NET en ningún caso estén configuradas para coexistir en el mismo grupo de aplicaciones. Cuando se comete este error, algo que es habitual, la primera solicitud carga el CLR del archivo aspnet_isapi.dll correspondiente y en las solicitudes posteriores a la otra versión del mismo grupo de aplicaciones se producirá un error.

IIS reconoce que el grupo de aplicaciones es la versión de ASP.NET en la que se selecciona ejecutar una aplicación. Por consiguiente, la versión de CLR/ASP.NET que se carga en el grupo de aplicaciones se configura explícitamente en el grupo de aplicaciones. De forma predeterminada, antes de cargar el proceso de trabajo IIS carga el CLR que se especifica en este valor (a menos que la versión esté configurada para estar vacía).

Dado que los grupos de aplicaciones son el límite del control de versiones de .NET Framework las siguientes operaciones permiten cambiar la versión de cualquier aplicación de ASP.NET:

  1. Mover la aplicación a un grupo de aplicaciones que use la versión de ASP.NET deseada.
    De forma predeterminada, las aplicaciones usan el grupo de aplicaciones predeterminado denominado "DefaultAppPool", que ejecuta ASP.NET v2.1 en modo Integrado. Mueva la aplicación a "Classic .NET AppPool" para que se ejecute en el modo Clásico de la versión 2.1 de ASP.NET, o al grupo de aplicaciones que prefiera.
  2. Configure el grupo de aplicaciones en el que se ejecuta la aplicación para que use la versión de ASP.NET deseada.
    De forma predeterminada, todos los grupos de aplicaciones nuevos están configurados para ejecutar ASP.NET v2.1 en modo Integrado.

Nota:

No use las opciones aspnet_regiis /i o /r para configurar la versión de ASP.NET para una aplicación determinada ni globalmente.

IIS usa asignaciones de controladores con condiciones previas para seleccionar automáticamente el conjunto correcto de asignaciones de controladores (a ASPNET_isapi.dll en el modo Clásico o directamente a los tipos de controlador administrados en el modo Integrado) en función de la versión de CLR configurada y el modo de integración administrado del grupo de aplicaciones. El programa de instalación de ASP.NET 2.0 instala estas asignaciones de controladores en el nivel de servidor.

Aprovechar el modo Integrado de ASP.NET

En IIS, las aplicaciones de ASP.NET se ejecutan en modo Integrado de forma predeterminada. Sin embargo, para aprovechar las ventajas que proporciona una integración más estrecha, es preciso realizar algunas modificaciones en la configuración de la aplicación. También puede desarrollar nuevos componentes de ASP.NET que aprovechen el modo Integrado para proporcionar una funcionalidad eficaz a la aplicación.

Habilitación de los servicios de ASP.NET para todos los tipos de contenido

En el modo Integrado, los servicios que proporcionan los módulos de ASP.NET están disponibles para las solicitudes de todos los tipos de contenido. Sin embargo, de forma predeterminada, los módulos de ASP.NET están configurados para ejecutarse solo en las solicitudes de contenido de ASP.NET por motivos de compatibilidad con versiones anteriores.

Para ello, adjunte una condición previa managedHandler a cada módulo de ASP.NET de la sección de configuración en el nivel de servidor:

<modules> 
     <add name="FormsAuthentication" type="System.Web.Security.FormsAuthenticationModule" 
             preCondition="managedHandler" />
     <add name="UrlAuthorization" type="System.Web.Security.UrlAuthorizationModule" 
             preCondition="managedHandler" />
    ...
</modules>

La condición previa es una regla que el servidor evalúa en cada solicitud para determinar si se ejecutará un módulo. La condición previa managedHandler solo es verdadera para las solicitudes a los tipos de contenido que se asignan a los controladores de ASP.NET.

Para aplicar la funcionalidad que proporcionan los módulos de ASP.NET a todas las solicitudes, quite la entrada del módulo y vuelva a agregarla sin la condición previa al archivo Web.config raiz de la aplicación.

Para habilitar la autenticación mediante formularios de ASP.NET para toda la aplicación, modifique el archivo Web.config como se indica a continuación:

<modules> 
    <remove name="FormsAuthentication" /> 
    <add name="FormsAuthentication" type="System.Web.Security.FormsAuthenticationModule" /> 
    …
</modules>

Con este cambio, el módulo FormsAuthentication se ejecuta en todas las solicitudes de la aplicación. Esto le permite proteger todo el contenido de la aplicación con autenticación mediante formularios. Para más información sobre cómo sacar provecho del modo Integrado para proporcionar autenticación mediante formularios a todo el contenido de la aplicación, consulte el tutorial sobre cómo aprovechar el modo Canalización integrada.

También puede usar un acceso directo para que todos los módulos administrados (ASP.NET) se puedan ejecutar en todas las solicitudes de la aplicación, independientemente de la condición previa "managedHandler". Para que todos los módulos administrados se puedan ejecuten en todas las solicitudes sin tener que configurar cada entrada de módulo para quitar la condición previa "managedHandler", use la propiedad runAllManagedModulesForAllRequests en la sección <modules>:

<modules runAllManagedModulesForAllRequests="true" />

Cuando se usa, la condición previa "managedHandler" deja de tener efecto y todos los módulos administrados se ejecutarán en todas las solicitudes.

Pruebe a habilitar otros módulos de ASP.NET para aplicarlos a toda la aplicación. Por ejemplo, use el módulo Caché de salida de ASP.NET para generar páginas ASP de caché o use la autorización de direcciones URL y el administrador de roles para configurar reglas de control de acceso para las fotos. O bien, desarrolle su propio módulo para que la eficacia de ASP.NET llegue a todo el sitio web.

Creación de servicios de ASP.NET más eficaces

En el modo Integrado, los módulos de ASP.NET aplican sus servicios a todo el contenido. Además, como en el modo Integrado los módulos de ASP.NET se ejecutan en la canalización unificada de procesamiento de solicitudes, se suscriben a las mismas fases de procesamiento de solicitudes y realizan las mismas tareas que los módulos del servidor nativo. Al mismo tiempo, las API de ASP.NET cambian muy poco, hay pocas incorporaciones importantes que desbloqueen las funcionalidades que anteriormente no estaban disponibles.

Fidelidad del runtime

En el modo Integrado, las fases del procesamiento de solicitudes de ASP.NET que se exponen en los módulos se conectan directamente a las fases correspondientes de la canalización de IIS. La canalización completa contiene las siguientes fases, que se exponen como eventos HttpApplication en ASP.NET:

  1. BeginRequest. Comienza el procesamiento de la solicitud.
  2. AuthenticateRequest. Si la solicitud está autenticada. Los módulos de autenticación de IIS y ASP.NET se suscriben a esta fase para realizar la autenticación.
  3. PostAuthenticateRequest.
  4. AuthorizeRequest. La solicitud está autorizada. Los módulos de autenticación de IIS y ASP.NET comprueban si el usuario autenticado tiene acceso al recurso solicitado.
  5. PostAuthorizeRequest.
  6. ResolveRequestCache. Los módulos de la memoria caché comprueban si la respuesta a esta solicitud existe en dicha memoria y la devuelven. en lugar de continuar con el resto de la ruta de acceso de ejecución. Se ejecutan las características Caché de salida de ASP.NET como Caché de salida de IIS.
  7. PostResolveRequestCache.
  8. MapRequestHandler. Esta fase es interna en ASP.NET y se usa para determinar el controlador de solicitudes.
  9. PostMapRequestHandler.
  10. AcquireRequestState. Se recupera el estado necesario para la ejecución de la solicitud. Los módulos Estado de sesión y Perfil de ASP.NET obtienen sus datos.
  11. PostAcquireRequestState.
  12. PreExecuteRequestHandler. Se realizan las tareas previas a la ejecución del controlador.
  13. ExecuteRequestHandler. Se ejecuta el controlador de solicitudes. Se sirven las páginas de ASPX, las páginas de ASP, los programas de CGI y los archivos estáticos.
  14. PostExecuteRequestHandler
  15. ReleaseRequestState. Aquí se guardan los cambios en el estado de la solicitud y se limpia el estado. Los módulos Estado de sesión y Perfil de ASP.NET usan esta fase para la limpieza.
  16. PostReleaseRequestState.
  17. UpdateRequestCache. La respuesta se almacena en la memoria caché para usarla en el futuro. Los módulos Caché de salida de ASP.NET y Caché de salida de IIS se ejecutan para guardar la respuesta en sus memorias caché.
  18. PostUpdateRequestCache.
  19. LogRequest. En esta fase se registran los resultados de la solicitud y se garantiza que se ejecute aunque se produzcan errores.
  20. PostLogRequest.
  21. EndRequest. Esta fase realiza la limpieza final de la solicitud y se garantiza que se ejecuta aunque se produzcan errores.

Mediante el uso de las conocidas API de ASP.NET, la capacidad de ejecutarse en las mismas fases que los módulos de IIS hace que aquellas tareas a las que anteriormente solo se podía acceder en los filtros y extensiones ISAPI nativos ahora son posibles en el código administrado.

Por ejemplo, ahora puede escribir módulos que realicen las siguientes operaciones:

  1. Intercepte la solicitud antes de cualquier procesamiento, por ejemplo, volver a escribir direcciones URL o realizar el filtrado de seguridad.
  2. Sustituya los modos de autenticación integrados.
  3. Modifique el contenido de la solicitud entrante, como los encabezados de la solicitud.
  4. Filtre las respuestas salientes para todos los tipos de contenido.

Para obtener un buen ejemplo de cómo ampliar IIS con un módulo de autenticación de ASP.NET personalizado, consulte Desarrollo de módulos de IIS 7 y versiones posteriores con .NET.

API de ASP.NET expandidas

Las API de ASP.NET siguen siendo compatibles con las versiones anteriores, lo que permite que los módulos existentes no solo funcionen tanto en IIS 7 como en las versiones posteriores sin modificaciones, sino también que se apliquen a todo el contenido de la aplicación sin cambios en el código.

Sin embargo, los módulos escritos para el modo Integrado de IIS pueden aprovechar algunas API adicionales para habilitar escenarios clave del procesamiento de solicitudes que no estaban disponibles anteriormente.

La nueva colección HttpResponse.Headers permite a los módulos inspeccionar y manipular los encabezados de respuesta que generan otros componentes de la aplicación. Por ejemplo, puede cambiar el encabezado Content-Type que genera una página ASP para solicitar un cuadro de diálogo de descarga en el explorador. La colección Cookies de la clase HttpResponse también se mejora para permitir la modificación de cookies que se generan como parte del procesamiento de solicitudes, incluso si se crearon fuera de ASP.NET.

La colección HttpRequest.Headers está habilitada para escritura, lo que permite a los módulos manipular los encabezados de solicitud entrantes. Úselo para cambiar el comportamiento de otros componentes del servidor. Por ejemplo, puede forzar que una aplicación localizada responda al cliente en otro idioma cambiando dinámicamente el valor del encabezado Accept-Language.

Por último, la colección HttpRequest.ServerVariables ahora se puede escribir, lo que permite establecer variables de servidor de IIS. Los módulos de ASP.NET usan esta funcionalidad para cambiar los valores que proporciona IIS y para crear variables de servidor que pueden ver otros marcos de aplicaciones, como PHP.

Integración de runtime

Además de las nuevas API, el modo Integrado permite que la funcionalidad de ASP.NET existente aporte más valor a la aplicación.

Las instalaciones de seguimiento que proporciona ASP.NET, entre las que se incluyen la clase System.Diagnostics.Trace y la característica de seguimiento de páginas de ASP.NET, ahora emiten información de seguimiento en el sistema de seguimiento de IIS. Esto permite colocar en un único archivo de registro la información de seguimiento que generan durante el procesamiento de solicitudes los componentes de IIS y de ASP.NET, lo que facilita el diagnóstico de los problemas del servidor.

La característica de filtrado de respuestas de ASP.NET, que permite cambiar las respuestas mediante una interfaz de Stream antes de que lleguen al cliente, se mejora para permitir el filtrado de contenido que no sea de ASP.NET. Por consiguiente, puede usar el filtrado de ASP.NET filtrado en todo el contenido del servidor, o bien puede instalar de forma selectiva el filtro solo para las solicitudes en el contenido que desea procesar. Con esta funcionalidad, puede escribir características de filtrado que inserten o censuren el contenido de las respuestas del sitio, independientemente de que este contenido proceda de una página ASPX o de un archivo estático.

Resumen

La integración de ASP.NET tanto en IIS 7 como en las versiones posteriores desbloquea todo el potencial de ASP.NET, lo que permite a los desarrolladores crear eficaces componentes de servidor con la facilidad y riqueza de ASP.NET y .NET Framework. Para más información sobre cómo sacar provecho del modo Integrado de ASP.NET en las aplicaciones existentes, consulte Aprovechar el modo Canalización integrada. Para obtener información sobre cómo crear nuevos componentes de ASP.NET para ampliar el servidor, consulte Desarrollo de un módulo de IIS 7 y versiones posteriores con .NET.