Integração do ASP.NET com o IIS 7

por Mike Volodarsky

Introdução

Desde seu lançamento, o ASP.NET tem sido a plataforma escolhida para desenvolver aplicativos Web na plataforma Windows/IIS. O ASP.NET 2.0 elevou o desenvolvimento de aplicativos Web a um novo patamar, permitindo que os desenvolvedores criem aplicativos mais poderosos em uma velocidade nunca antes vista.

O IIS 7 e versões posteriores aprimoraram o ASP.NET ao integrar o modelo de extensibilidade de runtime do ASP.NET com o servidor principal. Isso permite que os desenvolvedores estendam totalmente o servidor IIS com o .NET Framework e com todos os recursos do ASP.NET 2.0, em vez de usar as APIs C++ menos poderosas do IIS. Os aplicativos ASP.NET existentes também se beneficiam imediatamente de uma integração mais rigorosa ao usar os recursos existentes do ASP.NET, como autenticação do Forms, funções e cache de saída para todo o conteúdo.

Embora o IIS forneça uma integração aprimorada do ASP.NET por padrão, há uma opção: o IIS suporta os modos de integração novos e antigos do ASP.NET que podem ser usados lado a lado no mesmo servidor.

Este artigo discute as melhorias introduzidas pelo modo de integração do ASP.NET, a arquitetura dos dois modos e descreve como selecionar e configurar os modos de integração para aplicativos ASP.NET.

Aprimoramentos do ASP.NET no IIS 7 e versões superiores

A integração melhorada do ASP.NET no IIS aprimora os aplicativos existentes e também permite que novos aplicativos usufruam dos recursos do ASP.NET das seguintes maneiras:

• Os serviços ASP.NET podem ser usados para todos os tipos de conteúdo. No passado, as funcionalidades do ASP.NET, como autenticação do Forms, funções, autorização de URL e cache de saída, só estavam disponíveis para os tipos de conteúdo ASP.NET como páginas ASPX. Arquivos estáticos, páginas ASP e outros tipos de conteúdo não podiam usar esses serviços.

No IIS, todos os serviços ASP.NET são fornecidos uniformemente para todo o conteúdo. Por exemplo, você pode proteger todo o conteúdo da Web, incluindo imagens e páginas ASP, usando sua solução atual de controle de acesso ASP.NET 2.0, criada com base em controles de autenticação do Forms, afiliação e logon do ASP.NET.

• Estenda totalmente o IIS com ASP.NET. As versões anteriores do IIS frequentemente exigiam que a extensibilidade do servidor fosse desenvolvida usando o filtro ISAPI nativo ou o modo de extensibilidade de extensão devido às limitações de runtime do ASP.NET.

O IIS permite que os módulos ASP.NET se conectem diretamente ao pipeline do servidor, com a mesma fidelidade de runtime que os módulos desenvolvidos com a API nativa (C++) do servidor. Os módulos ASP.NET podem ser executados em todos os estágios do runtime do pipeline de processamento de solicitações e em qualquer ordem em relação aos módulos nativos. A API do ASP.NET também foi expandida para permitir maior controle sobre o processamento de solicitações.

• Runtime unificado do servidor. A integração mais rígida do ASP.NET também unifica muitos dos recursos entre o IIS e o ASP.NET.

O IIS fornece uma configuração unificada para módulos e manipuladores do IIS e do ASP.NET. Muitos outros recursos, incluindo erros personalizados e rastreamento, foram unificados para permitir um melhor gerenciamento e design de aplicativo coeso.

Arquitetura de integração do ASP.NET

No IIS 6.0 e versões anteriores, o ASP.NET foi implementado como uma extensão ISAPI do IIS.

Nessas versões anteriores, o IIS processava a solicitação do tipo de conteúdo ASP.NET e encaminhava essa solicitação para a DLL ISAPI do ASP.NET, que por sua vez hospedava o pipeline da solicitação ASP.NET e a estrutura da página. Solicitações para conteúdo que não era do ASP.NET, como páginas ASP ou arquivos estáticos, eram processadas pelo IIS ou outras extensões ISAPI e não ficavam visíveis para o ASP.NET.

A principal limitação desse modelo era que os serviços fornecidos por módulos ASP.NET e código de aplicativo ASP.NET personalizado não ficavam disponíveis para as solicitações não ASP.NET. Além disso, os módulos ASP.NET não conseguiam interferir em determinadas partes do processamento de solicitações do IIS que ocorriam antes e depois do caminho de execução do ASP.NET.

Figura 1: IIS 6.0 e pipelines do ASP.NET

No IIS, o pipeline de processamento de solicitações ASP.NET sobrepõe diretamente o pipeline do IIS, basicamente fornecendo um wrapper sobre ele em vez de conectá-lo.

O IIS processa as solicitações que chegam para qualquer tipo de conteúdo, com módulos nativos do IIS e módulos ASP.NET fazendo o processamento de solicitações em todos os estágios. Assim, os serviços fornecidos por módulos ASP.NET, como autenticação do Forms ou cache de saída, podem ser usados para solicitações a páginas ASP, páginas PHP, arquivos estáticos e assim por diante.

A capacidade de se conectar diretamente ao pipeline do servidor permite que os módulos ASP.NET substituam, executem antes ou executem após qualquer funcionalidade do IIS. Isso permite, por exemplo, criar um módulo personalizado de autenticação Básica ASP.NET para usar o serviço de afiliação e o banco de dados de usuários do SQL Server para substituir o recurso de autenticação Básica interna do IIS que funciona apenas com contas do Windows.

Além disso, as APIs ASP.NET expandidas usam integração direta para habilitar mais tarefas de processamento de solicitações. Por exemplo, os módulos ASP.NET podem modificar cabeçalhos de solicitações antes que outros componentes processem as solicitações, inserindo um cabeçalho Accept-Language antes que os aplicativos ASP sejam executados, o que força o conteúdo localizado a ser enviado de volta ao cliente com base na preferência do usuário.

Figura 2: Modo Integrado do IIS 7 e versões posteriores

Devido à integração do runtime, o IIS e o ASP.NET podem usar a mesma configuração para habilitar e ordenar os módulos do servidor e configurar mapeamentos do manipulador. Outras funcionalidades unificadas incluem rastreamento, erros personalizados e cache de saída.

Compatibilidade

Sobretudo, a arquitetura mantém as APIs e a arquitetura de runtime do ASP.NET, o que permite que aplicativos e serviços ASP.NET existentes funcionem depois da instalação. Com algumas modificações, os aplicativos e serviços ASP.NET existentes podem usufruir dos novos recursos do ASP.NET.

Da mesma forma, os desenvolvedores podem continuar a codificar novos aplicativos para as já conhecidas APIs ASP.NET enquanto aproveitam os benefícios da integração do runtime.

O IIS continua fornecendo o modo ASP.NET Clássico para aplicativos ASP.NET que têm requisitos de compatibilidade específicos que não são atendidos pelo Modo Integrado. Os administradores podem selecionar o modo de integração desejado por pool de aplicativos e, assim, os aplicativos que usam os modos novos e clássicos do ASP.NET podem funcionar lado a lado no mesmo servidor.

Migração de aplicativos ASP.NET para o Modo Integrado do IIS 7 e versões posteriores

No IIS, por padrão, o ASP.NET fica configurado para operar no novo Modo Integrado. Isso permite que seu aplicativo usufrua dos aprimoramentos do Modo Integrado com modificações mínimas.

Devido à unificação de configuração, alguns aplicativos podem exigir a migração para operar corretamente no Modo Integrado. Por padrão, o servidor fornece ajuda com a migração. Ele detecta aplicativos que exigem migração e retorna uma mensagem de erro solicitando que você migre o aplicativo.

A configuração a seguir causa o erro de migração:

1. O arquivo Web.config do aplicativo define a configuração do <httpModules>.
   O aplicativo carrega novos módulos ASP.NET ou remove os existentes.
   No Modo Integrado, os módulos ASP.NET são especificados com módulos nativos na seção de configuração unificada <system.webServer>/<modules>.
   Os módulos ASP.NET especificados na seção de configuração <system.web>/<httpModules> devem ser movidos para a nova seção de configuração para que funcione. Posteriormente, os novos módulos ASP.NET devem ser adicionados diretamente à seção <modules> unificada.
2. O arquivo Web.config do aplicativo define a <httpHandlers>configuração.
   O aplicativo usa mapeamentos personalizados do manipulador para alguns tipos de conteúdo.
   No Modo Integrado, os mapeamentos do manipulador ASP.NET devem ser especificados na seção de configuração unificada <system.webServer>/<handlers> para que funcione. Posteriormente, o novo manipulador ASP.NET deve ser adicionado diretamente à seção <handlers> unificada.
   Esta seção substitui a configuração <httpHandlers> do ASP.NET e também a configuração de mapas de script do IIS, que antes tinham que ser configuradas para definir um mapeamento do manipulador ASP.NET.
3. O arquivo Web.config do aplicativo define a configuração <identity impersonate="true" />.
   O aplicativo representa as credenciais do cliente, o que é mais comum nos aplicativos da rede privada. No Modo Integrado do IIS 7, a representação do cliente não está disponível em alguns estágios iniciais do processamento de solicitações. Na maioria dos casos, isso não é um problema e você pode desabilitar o erro de migração. Se não quiser desabilitar o erro, configure esse aplicativo para ser executado usando o modo ASP.NET Clássico.

Quando o erro de migração é gerado, geralmente ele migra a configuração do aplicativo (recomendado nos casos 1 e 2 acima) ou move o aplicativo para usar o modo ASP.NET Clássico (no caso 3).

Migração da Configuração do Aplicativo

O IIS migra o aplicativo usando a ferramenta de linha de comando AppCmd.exe para executar a migração. A mensagem de erro de migração contém o comando executado na janela de linha de comando, o qual você deve executar com direitos de usuário administrador para migrar instantaneamente seu aplicativo para o Modo Integrado.

O formato básico do comando de migração é:

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

Em que o <Caminho do Aplicativo> é o caminho virtual do aplicativo que contém o nome do site, como "Site padrão/aplicativo1".

Depois que a migração for concluída, seu aplicativo será executado tanto Modo Integrado quanto no Clássico sem problemas.

Observação

Se você alterar a configuração após a migração, o servidor não solicitará que você migre novamente. Após a migração inicial, você deve manter a configuração sincronizada entre os dois modos. Você pode migrar manualmente o aplicativo novamente usando a ferramenta de linha de comando AppCmd.exe.

Voltando para o Modo de integração ASP.NET Clássico

Se você preferir retornar ao modo ASP.NET Clássico, mova seu aplicativo para um pool de aplicativos configurado para ser executado no modo Clássico. Os outros aplicativos continuarão sendo executados no novo Modo Integrado lado a lado com os aplicativos no Modo Clássico.

Para obter mais informações sobre como mover um aplicativo para o Modo ASP.NET Clássico, consulte Alteração dos modos do ASP.NET de um aplicativo.

Desabilitar mensagem de erro de migração

Se você migrou manualmente sua configuração ou quiser permanecer no Modo Integrado sem migrar sua configuração (não recomendado), desabilite a mensagem de erro de migração adicionando o seguinte ao arquivo Web.config do aplicativo:

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

Observação

O servidor desabilita automaticamente a mensagem de erro depois de migrar a configuração com a ferramenta de linha de comando AppCmd.exe.

Se você desabilitar manualmente a mensagem de erro de migração, deverá assegurar que seu aplicativo funcione corretamente no Modo Integrado, pois o servidor não mostrará mais avisos sobre configurações sem suporte.

Alteração dos modos do ASP.NET de um aplicativo

Se seu aplicativo não funcionar corretamente no Modo ASP.NET Integrado, você poderá movê-lo para o Modo ASP.NET Clássico colocando em um outro pool de aplicativos. Cada pool de aplicativos é configurado individualmente para usar o modo de integração desejado do ASP.NET. Isso permite que você execute grupos de aplicativos que usam diferentes modos de integração do ASP.NET lado a lado no mesmo servidor.

Para alterar o modo de integração do ASP.NET de um aplicativo:

1. Localize ou crie um pool de aplicativos configurado para usar o modo desejado.
   Por padrão, todos os novos pools de aplicativos são executados no Modo Integrado.
   A configuração do ASP.NET fornece um pool de aplicativos chamado "Classic .NET AppPool" que é executado no modo de integração ASP.NET Clássico. Você pode usar esse pool de aplicativos para aplicativos que não devem ser executados no Modo Integrado.
   Também pode alterar o modo ASP.NET do pool dos aplicativos existentes usando a Ferramenta de Administração do IIS, a ferramenta de linha de comando AppCmd.exe ou editando manualmente a configuração do pool de aplicativos.
2. Defina o aplicativo para usar esse pool de aplicativos.
   Cada aplicativo deve ser configurado para usar um pool de aplicativos específico. Por padrão, todos os aplicativos usam o pool de aplicativos padrão chamado "DefaultAppPool", que é executado no Modo Integrado.
   Você pode alterar o pool de aplicativos de um aplicativo usando a Ferramenta de Administração do IIS, a ferramenta de linha de comando AppCmd.exe ou editando manualmente a configuração do aplicativos.

Seleção da versão ASP.NET para um aplicativo

Historicamente, o IIS suporta várias versões do ASP.NET/CLR executando lado a lado. Por exemplo, o IIS permite que o mesmo servidor execute aplicativos ASP.NET usando o .NET Framework v1.1 e v2.0. Esse suporte foi fornecido mapeando uma versão correspondente do ASPNET_isapi.dll para atender às solicitações do conteúdo ASP.NET usando a configuração de mapa de scripts do IIS.

Por exemplo, você pode usar a configuração de mapa de script a seguir para habilitar o suporte lado a lado:

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

Quando o aplicativo recebe uma solicitação *.aspx, o IIS carrega o aspnet_isapi.dll especificado, que por sua vez carrega a versão correta do CLR no processo de trabalho e processa a solicitação.

O ASP.NET também fornece as seguintes maneiras de configurar mapas de script lado a lado:

1. Extensão MMC ASP.NET. Quando você escolhe a versão de ASP.NET a ser usada, a extensão configura automaticamente os mapas de script do aplicativo para apontar para a versão correta do aspnet_isapi.dll.
2. ASP.NET aspnet_regiis.exe. Use as opções –i e –r para instalar os mapas de script que apontam para a versão correspondente do ASP.NET.

Infelizmente, devido à limitação da capacidade de carregar apenas uma versão do CLR em um único processo de trabalho, você deve garantir que dois aplicativos que usam versões diferentes do ASP.NET nunca sejam configurados para ficarem no mesmo pool de aplicativos. Quando esse erro comum é cometido, a primeira solicitação carregará o CLR do aspnet_isapi.dll correspondente e as solicitações subsequentes para a outra versão no mesmo pool de aplicativos falharão.

O IIS reconhece que o pool de aplicativos é a versão ASP.NET que você selecionaria para executar um aplicativo. Dessa forma, a versão do CLR/ASP.NET carregada no pool de aplicativos é explicitamente definida na configuração do pool de aplicativos. Por padrão, o IIS pré-carrega o CLR especificado por essa configuração no carregamento do processo de trabalho (a menos que a versão esteja configurada como vazia).

Como os pools de aplicativos são a última instância do controle de versões do .NET Framework, para alterar a versão de um aplicativo ASP.NET siga estes passos:

1. Mova o aplicativo para um pool de aplicativos que usa a versão desejada do ASP.NET.
   Por padrão, todos os aplicativos usam o pool de aplicativos padrão chamado "DefaultAppPool" que executa o ASP.NET v2.1 no Modo Integrado. Mova o aplicativo para o "Classic .NET AppPool" para executar o ASP.NET v2.1 no Modo Clássico ou em outro pool de aplicativos de sua escolha.
2. Configure o pool de aplicativos no qual o aplicativo está sendo executado para usar a versão desejada do ASP.NET.
   Por padrão, todos os novos pools de aplicativos são configurados para executar o ASP.NET v2.1 no Modo Integrado.

Observação

Não use as opções /i ou /r do aspnet_regiis para configurar a versão do ASP.NET para um aplicativo específico ou globalmente.

O IIS usa mapeamentos de manipulador pré-condicionados para selecionar automaticamente o conjunto correto de mapeamentos de manipulador (para ASPNET_isapi.dll no Modo Clássico ou diretamente para tipos de manipulador gerenciado no Modo Integrado) dependendo da versão do CLR configurada e do modo de integração gerenciada do pool de aplicativos. O ASP.NET 2.0 instala esses mapeamentos de manipulador no nível do servidor.

Usufruir o modo do ASP.NET integrado

No IIS, por padrão, os aplicativos ASP.NET são executados no Modo Integrado. No entanto, para usufruir dos benefícios fornecidos pela integração mais rigorosa, você deve fazer algumas modificações na configuração do aplicativo. Também é possível desenvolver novos componentes ASP.NET que utilizam o Modo Integrado para fornecer funcionalidade avançada ao seu aplicativo.

Habilitação dos serviços ASP.NET para todos os tipos de conteúdo

No Modo Integrado, os serviços fornecidos pelos módulos ASP.NET ficam disponíveis para solicitações de todos os tipos de conteúdo. No entanto, por padrão, os módulos ASP.NET são configurados para executar apenas solicitações de conteúdo ASP.NET para compatibilidade com versões anteriores.

Para fazer isso, no nível do servidor, anexe uma pré-condição managedHandler a cada módulo ASP.NET na seção de configuração:

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

A pré-condição é uma regra que o servidor avalia em cada solicitação para determinar se o módulo será executado. A pré-condição managedHandler só é verdadeira para solicitações de tipos de conteúdo mapeados para manipuladores ASP.NET.

Para aplicar a funcionalidade fornecida por um módulo ASP.NET a todas as solicitações, remova a entrada do módulo e adicione-a novamente sem a pré-condição no arquivo Web.config raiz do aplicativo.

Para habilitar a autenticação do ASP.NET Forms para todo o aplicativo, modifique o arquivo Web.config da seguinte maneira:

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

Com essa alteração, o módulo FormsAuthentication será executado para todas as solicitações em seu aplicativo. Isso permite proteger todo o conteúdo do aplicativo com a autenticação do Forms. Para obter mais informações sobre como aproveitar o Modo Integrado para fornecer autenticação do Forms para todo o conteúdo do aplicativo, consulte Utilização do tutorial do Modo Pipeline Integrado.

Você também pode usar um atalho para permitir que todos os módulos gerenciados (ASP.NET) sejam executados para todas as solicitações em seu aplicativo, independentemente da pré-condição "managedHandler". Para permitir que todos os módulos gerenciados sejam executados para todas as solicitações sem configurar cada entrada de módulo para remover a pré-condição "managedHandler", use a propriedade runAllManagedModulesForAllRequests na seção <modules>:

<modules runAllManagedModulesForAllRequests="true" />

Se você faz isso, a pré-condição "managedHandler" não funcionará e todos os módulos gerenciados serão executados para todas as solicitações.

Experimente permitir que outros módulos ASP.NET sejam aplicados a todo o seu aplicativo. Por exemplo, use o módulo ASP.NET Cache de Saída para armazenar em cache de saída as páginas ASP ou usar a Autorização de URL e o Gerenciador de Funções para configurar as regras de controle de acesso para suas fotos. Uma alternativa é desenvolver seu próprio módulo para usar toda a capacidade do ASP.NET em todo o seu site.

Criação de serviços ASP.NET mais poderosos

No Modo Integrado, os módulos ASP.NET aplicam os serviços deles a todo o conteúdo. Além disso, como os módulos ASP.NET são executados no Modo Integrado no pipeline unificado do processamento de solicitações, eles assinam os mesmos estágios de processamento de solicitações e executam as mesmas tarefas que os módulos do servidor nativo. Ao mesmo tempo, as APIs ASP.NET permanecem praticamente iguais, com algumas adições importantes que desbloqueiam a funcionalidade anteriormente indisponível.

Fidelidade de runtime

No Modo Integrado, os estágios do processamento de solicitações do ASP.NET expostos aos módulos ficam diretamente conectados aos estágios correspondentes do pipeline do IIS. O pipeline completo contém os estágios a seguir, que são expostos como eventos HttpApplication no ASP.NET:

1. BeginRequest. O processamento da solicitação é iniciado.
2. AuthenticateRequest. A solicitação é autenticada. Os módulos de autenticação do IIS e do ASP.NET assinam esse estágio para executar a autenticação.
3. PostAuthenticateRequest.
4. AuthorizeRequest. A solicitação é autorizada. Os módulos de autorização do IIS e do ASP.NET verificam se o usuário autenticado tem acesso ao recurso solicitado.
5. PostAuthorizeRequest.
6. ResolveRequestCache. Os módulos de cache verificam se a resposta a essa solicitação existe no cache e a retornam em vez de prosseguir com o restante do caminho de execução. Os recursos do Cache de Saída tanto do ASP.NET quanto do IIS são executados.
7. PostResolveRequestCache.
8. MapRequestHandler. Esse estágio é executado internamente no ASP.NET e é usado para determinar o manipulador de solicitação.
9. PostMapRequestHandler.
10. AcquireRequestState. O estado necessário para a execução da solicitação é recuperado. Os módulos Estado da Sessão e Perfil do ASP.NET obtêm os respectivos dados.
11. PostAcquireRequestState.
12. PreExecuteRequestHandler. Todas as tarefas antes da execução do manipulador são executadas.
13. ExecuteRequestHandler. O manipulador de solicitações é executado. Páginas ASPX, páginas ASP, programas CGI e arquivos estáticos são atendidos.
14. PostExecuteRequestHandler
15. ReleaseRequestState. Nesse ponto, as alterações de estado da solicitação são salvas e o estado é limpo. Os módulos Estado da Sessão e Perfil do ASP.NET usam esse estágio para fazer a limpeza.
16. PostReleaseRequestState.
17. UpdateRequestCache. A resposta é armazenada no cache para uso futuro. Os módulos Cache de Saída do ASP.NET e do IIS são executados para salvar a resposta nos respectivos caches.
18. PostUpdateRequestCache.
19. LogRequest. Esse estágio registra os resultados da solicitação e é executado mesmo que ocorram erros.
20. PostLogRequest.
21. EndRequest. Este estágio executa todas as limpezas de solicitações finais e é executado mesmo que ocorram erros.

Ao usar as APIs conhecidas do ASP.NET, o recurso de executar nos mesmos estágios que os módulos do IIS faz com que as tarefas que antes eram acessíveis somente por meio de filtros e extensões nativos do ISAPI agora podem ser acessadas no código gerenciado.

Por exemplo, agora você pode criar módulos que fazem o seguinte:

1. Interceptar a solicitação antes que qualquer processamento tenha ocorrido, por exemplo, reescrever URLs ou executar filtros de segurança.
2. Substituir os modos de autenticação internos.
3. Modificar o conteúdo da solicitação recebida, como por exemplo, os cabeçalhos da solicitação.
4. Filtrar respostas enviadas de todos os tipos de conteúdo.

Consulte Desenvolvimento de Módulo do IIS 7 e versões posteriores com .NET para obter bons exemplos de como estender o IIS com um módulo de autenticação personalizado do ASP.NET.

APIs expandidas do ASP.NET

As APIs ASP.NET permanecem compatíveis com versões anteriores, o que permite que os módulos existentes funcionem no IIS 7 e versões posteriores sem necessidade de modificá-los e se apliquem a todo o conteúdo do aplicativo sem alterar o código.

No entanto, os módulos desenvolvidos para o Modo Integrado do IIS podem usufruir de algumas APIs adicionais para habilitar os principais cenários de processamento de solicitações que não estavam disponíveis anteriormente.

A nova coleção HttpResponse.Headers permite que os módulos inspecionem e manipulem cabeçalhos de resposta gerados por outros componentes do aplicativo. Por exemplo, você pode alterar o cabeçalho Content-Type gerado por uma página ASP para solicitar uma caixa de diálogo de download no navegador. A coleção Cookies da classe HttpResponse também foi aprimorada para permitir a modificação de cookies gerados como parte do processamento da solicitação, mesmo que tenham sido criados fora do ASP.NET.

A coleção HttpRequest.Headers está habilitada para gravação, o que permite que os módulos manipulem os cabeçalhos de solicitações recebidas. Use isso para alterar o comportamento de outros componentes do servidor. Por exemplo, você pode forçar um aplicativo localizado a responder ao cliente em um idioma diferente ao alterar dinamicamente o valor do cabeçalho Accept-Language.

Por fim, a coleção HttpRequest.ServerVariables agora pode ser gravada, o que permite definir as variáveis do servidor IIS. Os módulos ASP.NET usam essa funcionalidade para alterar os valores fornecidos pelo IIS e para criar novas variáveis de servidor, visíveis para outras estruturas de aplicativo, como o PHP.

Integração de runtime

Além das novas APIs, o Modo Integrado permite que a funcionalidade ASP.NET existente forneça mais valor ao seu aplicativo.

Agora, os recursos de rastreamento fornecidos pelo ASP.NET, incluindo a classe System.Diagnostics.Trace, e o recurso de rastreamento de páginas ASP.NET emitem informações de rastreamento para o sistema de rastreamento do IIS. Isso permite que as informações de rastreamento geradas durante o processamento de solicitações pelos componentes IIS e ASP.NET sejam colocadas em um único arquivo de log, facilitando um diagnóstico melhor dos problemas do servidor.

O recurso de filtragem de resposta do ASP.NET, que permite que as respostas sejam alteradas usando uma interface Stream antes de serem enviadas ao cliente, foi aprimorado para permitir a filtragem de conteúdo não ASP.NET. Portanto, é possível usar a filtragem ASP.NET em todo o conteúdo do servidor ou instalar seletivamente o filtro apenas para solicitações de conteúdo que você deseja processar. Com essa funcionalidade, você pode criar recursos de filtragem que injetam ou censuram determinado conteúdo nas respostas do site, independentemente de esse conteúdo vir de uma página ASPX ou de um arquivo estático.

Resumo

A integração do ASP.NET no IIS 7 e versões posteriores desbloqueia todo o potencial do ASP.NET, permitindo que os desenvolvedores criem componentes de servidor poderosos com a facilidade e a riqueza do ASP.NET e do .NET Framework. Para saber mais sobre como aproveitar o Modo Integrado do ASP.NET para os aplicativos existentes, consulte Utilização do Modo Pipeline Integrado. Para obter informações sobre como criar novos componentes ASP.NET para estender o servidor, consulte Desenvolvimento de Módulo do IIS 7 e versões posteriores com .NET.