ASP.NET과 IIS 7의 통합

서론

ASP.NET은 처음 발표된 이래 Windows/IIS 플랫폼에서 웹 응용 프로그램 개발시 가장 먼저 고려되는 플랫폼이 되었습니다. ASP.NET 2.0은 웹 응용 프로그램 개발을 완전히 새로운 수준으로 이끌었으며 개발자들이 보다 강력한 응용 프로그램을 과거의 그 어느때 보다 신속하게 작성할 수 있게 해주었습니다.

IIS 7은 ASP.NET 런타임 확장성 모듈과 핵심 서버를 통합해서 ASP.NET을 또 한 단계 끌어 올렸습니다. 이는 개발자가 저수준 IIS C++ APIs를 사용하지 않고도, ASP.NET 2.0과 .NET 프레임워크가 제공하는 풍부한 기능들만 사용해서 IIS 서버 전체를 확장할 수 있게 해줍니다. 게다가 기존 ASP.NET 응용 프로그램도 폼 인증, 역할, 그리고 출력 캐시 같은 ASP.NET으로부터 제공되는 기존 기능들을 모든 유형의 콘텐츠를 대상으로 확장할 수 있게 됨으로서, 견고한 통합으로부터 얻어지는 직접적인 이점을 즉시 누릴 수 있습니다.

물론, IIS 7이 진보된 ASP.NET 통합을 기본으로 제공하기는 하지만, 그 선택은 여전히 여러분의 몫으로 남겨져 있습니다. IIS 7은 하나의 서버에서 동시에 운영할 수 있는 새로운 통합 모드와 기존 통합 모드를 모두 지원합니다.

본문에서는 새로운 ASP.NET 통합 모드에 의해 소개된 개선점들과 두 가지 모드의 아키텍처, 그리고 ASP.NET 응용 프로그램을 위해 통합 모드를 선택하거나 구성하는 방법에 대해서 살펴봅니다.

IIS 7에서의 ASP.NET의 향상

보다 개선된 IIS 7과 ASP.NET의 통합은 기존의 응용 프로그램들을 향상시키고 새롭게 작성되는 응용 프로그램들이 ASP.NET 기능의 이점을 새로운 방법으로 누릴 수 있게 해줍니다.

1. ASP.NET의 서비스들이 모든 유형의 콘텐츠들을 대상으로 적용될 수 있습니다.
   지금까지 폼 인증, 역할, URL 권한 부여 그리고 출력 캐시 같은 ASP.NET의 기능들은 오직 ASP.NET 콘텐츠 유형(예를 들어, ASPX 페이지)들만 대상으로만 사용할 수 있었습니다. 정적 파일들과 ASP 페이지들, 그리고 다른 유형의 파일들은 이런 서비스들의 이점을 누릴 수 없었습니다.
   
   IIS 7에서 모든 ASP.NET 서비스들은 모든 콘텐츠들을 대상으로 일관되게 제공될 수 있습니다. 가령, ASP.NET 인증, 멤버자격 그리고 로그인 컨트롤들로 작성된 이미 보유하고 있는 ASP.NET 2.0 접근 제어 솔루션을 사용해서, 이미지 파일과 ASP 페이지를 포함한 모든 콘텐츠들을 보호하는 것이 가능합니다.
2. ASP.NET을 사용해서 완벽한 IIS의 확장이 가능합니다.
   IIS의 과거 버전에서는 ASP.NET의 런타임 제약으로 인해 네이티브 ISAPI 필터나 확장 확장성 모드로 작성되는 서버 확장성이 빈번하게 요구되곤 했었습니다.
   
   IIS 7에서는 ASP.NET 모듈을 네이티브(C++) 서버 API를 사용해서 개발된 모듈과 완벽하게 동일한 방법으로 직접 서버의 파이프라인에 끼워 넣을수 있습니다. ASP.NET 모듈은 요청 처리 파이프라인의 모든 런타임 단계에서 실행될 수 있으며, 네이티브 모듈에 대해서 어떤 순서로도 실행되어질 수 있습니다. ASP.NET API 또한 이전에 가능했던 것보다 더 많은 요청 처리 제어를 위해 확장될 수 있습니다.
3. 통합된 서버 런타임.
   견고한 ASP.NET 통합은 IIS와 ASP.NET 간의 많은 기능들까지도 통합될 수 있게 해줍니다.
   IIS 7의 기능들은 IIS와 ASP.NET 모듈 그리고 핸들러에 대한 구성 설정을 통합합니다. 사용자 정의 오류, 그리고 추적을 포함한 다른 많은 기능들도 보다 나은 관리와 집중된 응용 프로그램 디자인을 위해 통합되었습니다.
   

IIS 7의 새로운 ASP.NET 모드가 제공하는 이점을 활용하는 방법에 대한 더 자세한 내용은 Taking Advantage of the Integrated ASP.NET mode를 참고하시기 바랍니다.

ASP.NET 통합 아키텍처

IIS 6와 그 이전의 릴리스들에서 ASP.NET은 IIS ISAPI 확장으로 구현되었습니다.

ASP.NET 콘텐츠 유형에 대한 요청은 먼저 IIS에 의해 처리되고, 그 뒤에 ASP.NET 요청 파이프라인과 페이지 프레임워크를 호스팅하는 ASP.NET ISAPI DLL로 전달됩니다. 반면, ASP 페이지나 정적 파일과 같은 비 ASP.NET 콘텐츠들에 대한 요청은 IIS나 다른 ISAPI 확장들에 의해 처리되며 ASP.NET쪽으로는 전혀 전달되지 않습니다.

이 모델의 가장 명확한 한계는 ASP.NET 모듈이나 사용자 정의 ASP.NET 응용 프로그램 코드가 비 ASP.NET 요청에 대해 그 어떠한 서비스도 제공할 수 없다는 점입니다. 더군다나 ASP.NET 실행 경로의 전과 후에 발생하는 IIS 요청 처리의 각각의 부분들에 대해서 ASP.NET 모듈은 일말의 영향도 미칠 수 없습니다.

그림 1: IIS 6.0 ASP.NET 통합. ASP.NET 요청은 우선 IIS에 의해 처리된 다음, ASP.NET 처리를 위해 ASP.NET ISAPI 확장으로 전달됩니다.

IIS 7에서는 ASP.NET 요청 처리 파이프라인이 IIS의 파이프라인에 직접적으로 중첩되며 이는 단순히 끼워 넣어지는 것이 아니라 본질적인 레퍼로 제공되는 것입니다.

콘텐츠 유형과 무관하게 도착한 모든 요청은 IIS에 의해 전체 과정의 모든 단계에서 요청 처리 제공이 가능한 네이티브 IIS 모듈과 ASP.NET 모듈 양쪽 모두를 통해서 처리됩니다. 바로 이 점으로 인해서 폼 인증이나 출력 캐시 같은 ASP.NET 모듈이 제공하는 서비스들을 ASP 페이지, PHP 페이지, 정적 파일 등에도 제공할 수 있게 되는 것입니다.

이처럼 서버 파이프라인에 ASP.NET 모듈을 직접 끼워 넣을 수 있기 때문에, ASP.NET 모듈로 IIS의 기능을 대체하거나 특정 IIS 기능이 실행되기 직전이나 직후에 ASP.NET 모듈을 실행하는 것이 가능합니다. 가령, 멤버십 서비스와 SQL 서버 사용자 데이터베이스를 사용하도록 작성된 사용자 정의 ASP.NET 기본 인증 모듈을 사용해서, Windows 계정에 대해서만 동작하는 내장 IIS 기본 인증 기능을 대체할 수도 있습니다.

게다가, 확장된 ASP.NET APIs는 요청 처리 작업에 대한 더 많은 직접 통합의 이점을 누립니다. 가령, ASP.NET 모듈은 ASP 응용 프로그램이 사용자 선호도에 따라 지역화된 콘텐츠를 클라이언트로 강제 전송하는 작업을 실행하기 전에 Accept-Language 헤더를 추가하는 등, 다른 구성 요소들이 특정 요청을 처리하기 전에 미리 해당 요청의 헤더 정보를 변경할 수도 있습니다.

그림 2: IIS 7 통합 모드. ASP.NET 구성 요소는 IIS 요청 처리 파이프라인에 직접 끼워 넣어지며, 콘텐츠 유형의 구분 없이 모든 요청을 대상으로 실행됩니다.

런타임 통합으로 인해서 IIS와 ASP.NET은 서버 모듈의 활성화와 정렬, 그리고 핸들러 맵핑 구성에 대해 동일한 구성 설정을 사용할 수 있게 되었습니다. 추적, 사용자 정의 오류, 그리고 출력 캐시 등을 포함한 다른 통합된 기능들도 마찮가지 입니다.

가장 주목할 만한 부분은 통합된 아키텍처가 기존의 ASP.NET 런타임 아키텍처와 APIs를 여전히 지원하므로, 기존 ASP.NET 응용 프로그램과 서비스 대부분이 수정을 거치지 않고서도 정상적으로 동작한다는 점입니다. 게다가 단지 약간의 수정만으로도 새로운 ASP.NET 기능들의 이점을 누리도록 변경할 수 있습니다.

ASP.NET 응용 프로그램을 통합 모드에서 실행할 수 있도록 설정하는 방법에 대한 더 자세한 정보는 IIS 7 통합 모드를 위한 ASP.NET 응용 프로그램의 마이그레이션을 참고하시기 바랍니다.

개발자들은 런타임 통합으로 인한 이득을 누리면서도 계속 친숙한 기존의 ASP.NET APIs를 사용해서 새로운 응용 프로그램을 작성할 수 있습니다.

IIS 7은 통합 모드에서 지원되지 않는 특수한 호환성이 요구되는 ASP.NET 응용 프로그램을 위한 "클래식" ASP.NET 모드도 지원합니다. 관리자는 응용 프로그램 풀 단위로 필요한 통합 모드를 선택할 수 있으며, 결과적으로 새로운 통합 모드를 사용하는 응용 프로그램과 클래식 ASP.NET 모드를 사용하는 응용 프로그램을 동일한 서버에서 함께 운영할 수 있습니다.

두 가지 ASP.NET 통합 모드간의 전환에 대한 더 많은 내용은 응용 프로그램을 위한 ASP.NET 모드 변경을 참고하시기 바랍니다.

IIS 7 통합 모드를 위한 ASP.NET 응용 프로그램의 마이그레이션

IIS 7은 기본적으로 ASP.NET이 새로운 통합 모드에서 동작하도록 구성되어 있습니다. 따라서, 응용 프로그램은 최소한의 변경만으로도 향상된 통합 모드의 이점을 얻을 수 있습니다.

구성 설정이 통합되었기 때문에 일부 응용 프로그램들은 통합 모드에서 운영되기 위해서는 마이그레이션이 필요할 수도 있습니다. 기본적으로 서버는 마이그레이션을 지원하기 위해 응용 프로그램이 마이그레이션을 필요로 하는지 감지하고, 응용 프로그램을 마이그레이션하기 위해 요구되는 내용들을 오류 메시지로 리턴합니다.

다음과 같은 구성 설정은 마이그레이션 오류를 발생시킵니다.

1. 응용 프로그램의 web.config 파일이 <httpModules> 구성 설정 섹션을 정의합니다.
   응용 프로그램이 새로운 ASP.NET 모듈을 로드하거나 기존 모듈 중 하나를 제거합니다. 통합 모드에서 ASP.NET 모듈은 네이티브 모듈과 함께 통합된 <system.webServer>/<modules> 구성 설정 섹션에 지정됩니다. <system.web>/<httpModules> 구성 설정 섹션에 지정된 ASP.NET 모듈이 정상적으로 동작하기 위해서는 새로운 구성 설정 섹션으로 이동되어야 합니다. 새로운 ASP.NET 모듈은 통합된 <modules> 섹션에 직접 추가되어야 합니다.
2. 응용 프로그램의 web.config 파일이 <httpHandlers> 구성 설정 섹션을 정의합니다.
   응용 프로그램이 일부 콘텐츠 유형을 대상으로 사용자 정의 핸들러 맵핑을 사용합니다. 통합 모드에서 ASP.NET 핸들러 맵핑이 정상적으로 동작하기 위해서는 통합된 <system.webServer>/<handlers> 구성 설정 섹션을 통해 지정되어야 합니다. 새로운 ASP.NET 핸들러 맵핑은 통합된 <handlers> 섹션에 직접 추가되어야 합니다. <handlers> 섹션은 이전 버전에서 ASP.NET 핸들러 맵핑을 설정하기 위해 사용되던 ASP.NET <httpHandlers> 구성 설정과 IIS 스크립트맵 구성 설정을 모두 대체합니다.
3. 응용 프로그램의 web.config 파일이 <identity impersonate="true" /> 구성 설정 섹션을 정의합니다.
   응용 프로그램이 클라이언트의 신원을 가장합니다. (대부분 인트라넷 응용 프로그램의 경우) 통합 모드에서 클라이언트 신원 가장 기능은 일부 초기 요청 처리 단계에서 사용이 불가능합니다. 이런 경우, 대부분 오류 발생을 무시하도록 설정해도 크게 문제가 되지 않으며 또는 응용 프로그램이 클래식 ASP.NET 모드에서 실행되도록 구성할 수도 있습니다.

이런 오류가 발생하는 경우, 일반적으로 응용 프로그램의 구성 설정을 마이그레이션(첫 번째나 두 번째 경우 추천)하거나, 응용 프로그램이 클래식 ASP.NET 모드를 사용하도록 전환(세 번째 경우 추천)할 수 있습니다.

응용 프로그램 구성 설정 마이그레이션

IIS 7은 마이그레이션 작업을 수행해주는 APPCMD.EXE 명령줄 도구를 통해서 여러분들의 응용 프로그램 마이그레이션 작업을 여러분 대신 처리해줄 수 있습니다. 대부분의 마이그레이션 오류 메시지에는 여러분들의 응용 프로그램을 통합 모드에 알맞게 즉시 마이그레이션 할 수 있게 해주는, 관리자 권한 명령어 실행창에서 실행 가능한 명령어가 포함되어 있습니다.

마이그레이션 명령어의 기본적인 형식은 다음과 같습니다.

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

[Application Path]에는, "기본 웹 사이트/app1" 같은 사이트 이름을 포함한 가상 경로가 위치합니다.

마이그레이션을 마치고 나면, 응용 프로그램은 통합 모드와 클래식 모드 양쪽에서 모두 정상적으로 동작할 것입니다.

일단 마이그레이션 후에는, 다시 구성 설정을 변경하더라도 서버가 다시 마이그레이션을 하라는 메시지를 지원하지 않는다는 점을 명심하기 바랍니다. 최초의 마이그레이션 작업이 끝난 다음부터 두 모드 사이의 구성 설정 동기화에 대한 모든 책임은 여러분의 몫입니다. 다시 한 번 APPCMD.EXE 명령줄 도구를 실행해서 수작업으로 응용 프로그램의 마이그레이션을 수행할 수 있습니다.

클래식 ASP.NET 통합 모드 전환

만약 다시 클래식 ASP.NET 모드를 사용하고 싶다면, 그저 간단히 응용 프로그램을 클래식 모드에서 실행되도록 구성된 응용 프로그램 풀로 이동하기만 하면 됩니다. 해당 응용 프로그램 외의 다른 모든 응용 프로그램들은 클래식 모드 응용 프로그램과 함께 여전히 새로운 통합 모드에서 실행될 것입니다.

응용 프로그램을 클래식 ASP.NET 모드로 이동하는 방법에 대한 더 많은 내용을 보시려면 응용 프로그램을 위한 ASP.NET 모드 변경을 참고하시기 바랍니다.

마이그레이션 오류 메시지 비활성화

만약 수작업으로 응용 프로그램을 마이그레이션하거나, 통합 모드를 사용함에도 불구하고 구성 설정을 마이그레이션하고 싶지 않다면(추천하지 않음), 응용 프로그램의 web.config 파일에 다음과 같은 구성 설정 섹션을 추가해서 마이그레이션 오류 메시지를 비활성화 시킬 수 있습니다.

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

노트: 앞에서 설명한 APPCMD.EXE 명령줄 도구를 사용해서 구성 설정을 마이그레이션하고 나면 서버는 자동으로 오류 메시지를 비활성화시킵니다.

만약 수작업으로 마이그레이션 오류 메시지를 비활성화시키면, 더이상 서버로부터 앞에서 살펴본 지원되지 않는 구성 설정에 대한 어떤 경고 메시지도 제공되지 않는 상태에서, 여러분 스스로가 통합 모드에서 응용 프로그램이 적절히 동작하도록 책임져야 합니다.

응용 프로그램을 위한 ASP.NET 모드 변경

만약 응용 프로그램이 통합된 ASP.NET 모드에서 올바르게 동작하지 않는다면, 응용 프로그램을 다른 응용 프로그램 풀로 이동해서 간단하게 클래식 ASP.NET 모드로 변경할 수 있습니다. 이는 각각의 응용 프로그램 풀이 개별적으로 필요한 통합 모드를 사용하도록 구성될 수 있기 때문에 가능한 일입니다. 게다가 이런 특징은 서로 다른 ASP.NET 통합 모드를 사용하는 응용 프로그램들의 그룹이 동일 서버에서 함께 실행될 수 있게 해줍니다.

응용 프로그램의 ASP.NET 통합 모드를 변경하려면 다음과 같이 하십시오.

1. 원하는 모드로 구성된 응용 프로그램 풀을 찾거나 생성하십시오.
   기본적으로 시스템의 모든 새로운 응용 프로그램 풀은 통합 모드에서 실행됩니다. ASP.NET은 Classic .NET AppPool이라는 이름의 클래식 ASP.NET 통합 모드로 실행되는 응용 프로그램 풀을 제공합니다. 새로운 통합 모드에서 실행되면 안되는 응용 프로그램들을 위해서 이 응용 프로그램 풀을 사용할 수 있습니다. 그리고, IIS 7 관리 도구나 APPCMD.EXE 명령줄 도구를 사용하거나, 수작업으로 응용 프로그램 풀 구성 설정을 변경해서 기존 응용 프로그램 풀의 ASP.NET 모드를 변경할 수도 있습니다.
2. 해당 응용 프로그램 풀을 사용하도록 응용 프로그램을 설정하십시오.
   각각의 응용 프로그램들은 개별적으로 응용 프로그램 풀을 사용하도록 구성됩니다. 기본적으로 모든 응용 프로그램은 통합 모드에서 동작하는 DefaultAppPool이라는 이름의 기본 응용 프로그램 풀을 사용합니다. IIS 7 관리 도구나 APPCMD.EXE 명령줄 도구를 사용하거나, 수작업으로 응용 프로그램의 응용 프로그램 풀 설정을 변경할 수 있습니다.

응용 프로그램을 위한 ASP.NET 버전 선택

역사적으로 IIS는 여러 버전의 ASP.NET/CLR을 동시에 지원해왔는데, 가령 동일한 서버에서 .NET 프레임워크 v1.1을 사용하는 ASP.NET 응용 프로그램과 .NET 프레임워크 v2.0을 사용하는 ASP.NET 응용 프로그램이 동시에 실행될 수 있습니다. 이런 지원은 IIS 스크립트맵 구성 설정을 기반으로 ASP.NET 콘텐츠 요청을 처리하기 위해 적절한 버전의 ASPNET_isapi.dll 파일이 맵핑됨으로서 제공됩니다.

예를 들어서, 동일한 서버에서 여러 버전의 ASP.NET/CLR을 동시에 지원하기 위해 다음과 같은 스크립트맵을 구성할 수 있습니다.

1. ASP.NET v1.1 응용 프로그램인 /app1:
   *.aspx -> d:\WINDOWS\Microsoft.NET\Framework\v1.1.4322\aspnet_isapi.dll
2. ASP.NET v2.0 응용 프로그램인 /app2:
   *.aspx -> d:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\aspnet_isapi.dll

응용 프로그램에 *.aspx 파일에 대한 요청이 도착하면 IIS는 지정된 aspnet_isapi.dll 파일을 로드하고, 이 로딩된 aspnet_isapi.dll 파일이 올바른 버전의 CLR을 작업자 프로세스에 로딩함으로서 해당 요청을 처리합니다.

그리고 ASP.NET은 동일한 서버에서 여러 버전의 ASP.NET/CLR을 동시에 지원하기 위한 다음과 같은 구성 방법을 제공합니다.

1. ASP.NET MMC 확장. 사용자가 사용하고자 하는 ASP.NET의 버전을 지정할 수 있으며, 확장은 자동적으로 응용 프로그램을 위한 올바른 버전의 aspnet_isapi.dll 파일을 지정해서 스크립트맵을 구성하게 됩니다.
2. ASP.NET aspnet_regiis.exe. 사용자는 적절한 ASP.NET 버전을 지정하는 스크립트맵을 설치하기 위해 -i 와 -r 옵션을 사용할 수 있습니다.

공교롭게도, 단일 작업자 프로세스에는 하나의 CLR 버전만 로드될 수 있다는 제약이 존재하기 때문에 서로 다른 버전을 사용하는 두 응용 프로그램이 같은 응용 프로그램 풀을 사용하게 구성되지 않도록 주의를 기울여야 합니다. 그렇지 않으면, 처음 요청으로 인해서 그에 대응하는 aspnet_isapi.dll 파일의 CLR이 로드되고, 직후에 뒤따라 발생한 같은 응용 프로그램 풀의 다른 버전에 대한 요청은 실패하게 됩니다.

IIS 7은 응용 프로그램 풀을 ASP.NET 버전 관리의 최소 단위로 간주합니다. 따라서, 응용 프로그램 풀에 로드되는 CLR/ASP.NET의 버전은 응용 프로그램 풀 구성 설정에 명확하게 설정됩니다. IIS는 작업자 프로세스가 로딩될 때 이 구성 설정에 지정된 버전의 CLR을 기본으로 미리 로드할 것입니다. (버전정보가 공백으로 설정된 경우는 제외)

응용 프로그램 풀이 .NET 프레임워크 버전 관리의 경계선이기 때문에 다음과 같은 작업은 ASP.NET 응용 프로그램의 버전에 변화를 주게 됩니다.

1. 원하는 ASP.NET 버전을 사용하는 응용 프로그램 풀로 응용 프로그램을 이동합니다.
   기본적으로 응용 프로그램은 ASP.NET v2.1 통합 모드로 실행되는 "DefaultAppPool"이라는 이름의 기본 응용 프로그램 풀을 사용합니다. ASP.NET v2.1 클래식 모드를 사용하기 위해서 응용 프로그램을 "Classic .NET AppPool"이라는 응용 프로그램 풀이나 여러분들이 선택한 다른 응용 프로그램 풀로 이동할 수 있습니다.
2. 응용 프로그램이 실행되는 응용 프로그램 풀을 원하는 ASP.NET 버전을 사용하도록 설정합니다.
   기본적으로 모든 새로운 응용 프로그램 풀은 ASP.NET 2.1 통합 모드에서 실행되도록 구성됩니다.

특정 응용 프로그램을 대상으로나 전반적으로 ASP.NET의 버전을 구성하기 위해서는 aspnet_regiis /i 또는 /r 옵션을 사용하면 안된다는 점에 주의하시기 바랍니다.

IIS 7은 설정된 CLR 버전과 응용 프로그램 풀의 관리되는 통합 모드에 따라 자동으로 핸들러 맵핑의 올바른 집합을 선택하기 위해서 (클래식 모드에서 ASPNET_isapi.dll 파일 또는 통합 모드에서 관리되는 핸들러 유형들을 위한) 미리 구성된 핸들러 맵핑을 사용합니다. 이런 핸들러 맵핑은 ASP.NET 2.0 설치시 서버 수준에서 설치됩니다.

통합된 ASP.NET 모드의 이용

기본적으로 IIS 7에서는 ASP.NET 응용 프로그램이 통합 모드로 실행됩니다. 그렇지만, 견고한 통합이 제공하는 이점을 활용하려면 응용 프로그램의 구성 설정을 일부 수정해야 합니다. 더 나아가, 응용 프로그램에 보다 강력한 기능을 부여하기 위해서 통합 모드를 이용하는 새로운 ASP.NET 구성 요소를 개발할 수도 있습니다.

모든 유형의 콘텐츠에 대한 ASP.NET 서비스 활성화

통합 모드에서 ASP.NET 모듈에 의해 제공되는 서비스들은 모든 유형의 콘텐츠 요청을 대상으로 실행될 수 있습니다. 그러나, 하위 호환성을 유지하기 위해서 기본적으로 ASP.NET 모듈은 ASP.NET 콘텐츠에 대한 요청만을 대상으로 실행되도록 구성되어 있습니다.

이는 서버 수준의 <modules> 구성 설정 섹션에 설정된 각각의 ASP.NET 모듈에 추가된 managedHandler 전제 조건 속성값으로 인해 얻어집니다.

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

이 preCondition 속성은 모듈이 모든 요청을 대상으로 실행되야 할지 말아야 할지 결정할 때 서버가 사용하는 기준값입니다. managedHandler 속성값은 현재 ASP.NET 핸들러와 맵핑되어 있는 콘텐츠 유형들에 대한 요청에 대해서만 ASP.NET 모듈이 실행되도록 지정합니다.

만약, ASP.NET 모듈이 제공하는 기능을 모든 요청을 대상으로 적용하려면, 모듈 항목을 제거하고 응용 프로그램의 최상위 web.config 파일에 preCondition 속성만 제외해서 다시 추가하면 됩니다. 가령, ASP.NET 폼 기반 인증을 응용 프로그램 전체를 대상으로 적용하고 싶다면 다음과 같이 지정하면 됩니다.

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

이렇게 변경하면 FormsAuthentication 모듈은 응용 프로그램에 대한 모든 요청을 대상으로 동작할 것입니다. 그리고, 폼 기반 인증 서비스가 응용 프로그램 콘텐츠 전체를 보호하게 됩니다.

그리고, "managedHandler" 전제 조건에 관계 없이 모든 관리되는 (ASP.NET) 모듈들이 응용 프로그램에 대한 모든 요청을 대상으로 동작하도록 활성화할 수 있는 손쉬운 방법도 존재합니다. 각각의 모듈 항목에서 일일이 "managedHandler" 전제 조건을 제거하지 않고서도 모든 요청을 대상으로 모든 관리되는 모듈을 활성화하려면, 다음과 같이 <modules> 섹션에 runAllManagedModulesForAllRequests 속성을 추가합니다.

<modules runAllManagedModulesForAllRequests="true" />

이 속성이 사용되면 "managedHandler" 전제 조건은 무시되고 모든 관리되는 모듈들은 모든 요청을 대상으로 동작합니다.

다른 ASP.NET 모듈들이 전체 응용 프로그램에 적용되도록 활성화시키는 실험을 해볼 수도 있습니다. 대표적인 경우로 ASP 페이지의 출력을 캐시하기 위해 ASP.NET 출력 캐시 모듈을 적용해본다거나, 사진에 대한 접근 제한 설정을 위해 Url 인증과 역할 관리자를 적용해 볼 수도 있습니다. 아니면, 직접 자신만의 모듈을 개발해서 전체 웹 사이트에 ASP.NET의 기능들을 적용할 수도 있습니다.

보다 강력한 ASP.NET 서비스의 구현

통합 모드에서 ASP.NET 모듈은 모든 콘텐츠를 대상으로 서비스를 제공할 수 있습니다. 게다가 통합 모드에서 ASP.NET은 통합된 요청 처리 파이프라인에서 실행되기 때문에, 네이티브 서버 모듈과 동일한 요청 처리 단계를 구독할 수 있으며 동일한 작업을 수행할 수 있습니다. ASP.NET APIs는 이전에는 사용할 수 없던 몇 가지 중요한 기능들이 제공되는 것을 제외한다면 대부분 예전과 동일합니다.

런타임 충실도

통합 모드에서 모듈에 노출되어 있는 ASP.NET 요청 처리 단계들은 IIS 파이프라인의 일치하는 단계에 직접적으로 연결되어 있습니다. 전체 파이프라인은 다음의 단계들을 포함하고 있으며, 이 단계들은 ASP.NET에서 HttpApplication 이벤트로 노출됩니다.

1. BeginRequest. 요청 처리를 시작합니다.
2. AuthenticateRequest. 요청이 인증됩니다. 이 단계에서 IIS와 ASP.NET 인증 모듈이 인증을 수행합니다.
3. PostAuthenticateRequest
4. AuthorizeRequest. 요청에 권한이 부여됩니다. IIS와 ASP.NET 권한 부여 모듈이 인증된 사용자에게 요청된 리소스에 접근할 권한이 있는지 검사합니다.
5. PostAuthorizeRequest
6. ResolveRequestCache. 캐시 모듈이 해당 요청에 대한 응답이 이미 캐시에 존재하는지 파악하고, 남아 있는 이후의 단계들을 실행하는 대신 캐시에 존재하는 응답을 리턴할 수 있습니다. ASP.NET 출력 캐시 기능과 새로운 IIS 출력 캐시 기능이 모두 이 단계에서 실행됩니다.
7. PostResolveRequestCache
8. MapRequestHandler. ASP.NET의 내부 단계며, 요청 핸들러가 결정됩니다.
9. PostMapRequestHandler
10. AcquireRequestState. 요청 실행을 위해 필요한 상태를 가져옵니다. ASP.NET 세션 상태, 그리고 프로파일 모듈들이 이 단계에서 데이터를 가져옵니다.
11. PostAcquireRequestState
12. PreExecuteRequestHandler. 핸들러가 실행되기 전에 필요한 일련의 작업들이 이 단계에서 실행될 수 있습니다.
13. ExecuteRequestHandler. 요청 핸들러가 실행됩니다. ASPX 페이지, ASP 페이지, CGI 프로그램, 그리고 정적 페이지들이 이 단계에서 처리됩니다.
14. PostExecuteRequestHandler
15. ReleaseRequestState. 변경된 요청 상태가 저장되고 정리됩니다. 이 단계에서 ASP.NET 세션 상태와 프로파일 모듈들의 상태가 정리됩니다.
16. PostReleaseRequestState
17. UpdateRequestCache. 다음에 사용될 응답이 캐시에 저장됩니다. 이 단계에서 ASP.NET 출력 캐시와 IIS 출력 캐시 모듈이 각각의 캐시에 응답을 저장하기 위해 실행됩니다.
18. PostUpdateRequestCache
19. LogRequest. 요청 처리 결과를 로그에 기록합니다. 만약, 오류가 발생하더라도 이 단계는 실행됩니다.
20. PostLogRequest
21. EndRequest. 일련의 마지막 처리가 수행됩니다. 만약 오류가 발생하더라도 이 단계는 실행됩니다.

통합 모드에서 실행되는 ASP.NET 요청 처리 단계들이 IIS 모듈과 같은 단계를 공유한다는 점은 과거 네이티브 ISAPI 필터나 확장을 사용해서만 가능했던 많은 작업들을 이제 친숙한 ASP.NET APIs와 풍부한 .NET 플랫폼의 기능들을 사용하는 관리되는 코드만으로도 가능하게 만들었습니다. 가령, 다음과 같은 작업을 처리하는 모듈을 작성할 수도 있습니다.

1. 요청이 다른 작업에 의해서 처리되기 전에 가로챌 수 있습니다. 가령, Url을 다시 기록하거나 보안 필터링을 실행할 수 있습니다.
2. 기본 제공되는 인증 모드를 교체할 수 있습니다.
3. 요청 헤더와 같은 들어오는 요청의 내용을 수정할 수 있습니다.
4. 모든 콘텐츠 유형의 나가는 응답을 필터링할 수 있습니다.

사용자 정의 ASP.NET 인증 모듈로 IIS를 확장하는 훌륭한 샘플을 .NET 프레임워크로 IIS 7 모듈 및 헨들러 개발하기에서 살펴보실 수 있습니다.

ASP.NET APIs 확장

ASP.NET APIs는 여전히 이전 버전과 하위 호환성을 유지하고 있는데, 이는 기존 모듈들이 수정 없이 IIS 7에서 동작할 수 있게 해주고 모든 응용 프로그램 콘텐츠의 코드 변경을 불필요하게 만들어줍니다.

그렇기는 하지만, IIS 7 통합 모드 전용으로 작성된 모듈들은 지금까지 처리가 불가능했던 핵심적인 요청 처리 시나리오를 지원하기 위해 추가된 몇 가지 APIs의 이점을 얻을 수 있습니다.

가령, 새로운 HttpResponse.Headers 컬렉션을 이용해서 다른 응용 프로그램 구성 요소에 의해서 생성된 요청 헤더를 모듈로 분석하거나 조작할 수 있습니다. 한 가지 예로, 브라우저에 다운로드 대화상자가 나타나도록 ASP 페이지에서 생성된 Content-Type 헤더를 변경할 수도 있습니다. 더군다나 HttpResponse 클래스가 제공하는 Cookies 컬렉션은 요청 처리 작업의 일부로 만들어진 쿠키를 수정할 수 있도록 개선되었으며, 심지어는 쿠키가 ASP.NET 외부에서 생성되었다고 하더라도 변함 없이 수정이 가능합니다.

또한, HttpRequest.Headers 컬렉션도 기록이 가능해졌으며 모듈에서 들어오는 요청 헤더를 조작할 수 있게 해줍니다. 이런 변화는 다른 서버 구성 요소의 동작을 변경하는데 사용될 수 있습니다. 예를 들어서, Accept-Language 헤더의 값을 동적으로 변경해서 지역화된 응용 프로그램이 다른 언어를 사용해서 클라이언트에게 응답하게 할 수 있습니다.

마지막으로 HttpRequest.ServerVariables 컬렉션도 역시 기록이 가능해졌으며 IIS 서버 변수들의 값을 설정할 수 있게 되었습니다. ASP.NET 모듈은 IIS가 제공하는 값들을 변경하거나 PHP 같은 다른 응용 프로그램 프레임워크에게 노출하기 위한 목적으로 새로운 서버 변수를 만들어 낼 수도 있습니다.

런타임 통합

새롭게 제공되는 APIs와 통합 모드는 기존의 ASP.NET의 기능들이 응용 프로그램에 보다 많은 가치를 제공해줄 수 있게 지원해줍니다.

이제 System.Diagnostics.Trace 클래스와 ASP.NET 페이지 추적 기능 등, ASP.NET으로부터 제공되는 추적 기능들은 추적된 정보를 IIS 추적 시스템에 출력할 수 있습니다. 결과적으로 IIS나 ASP.NET이 요청을 처리하면서 발생한 모든 추적 정보를 단일 로그 파일에 저장할 수 있게 되었으며 서버의 문제점들을 분석하기가 더욱 편리해졌습니다.

클라이언트로 응답이 전송되기 전에 스트림 인터페이스를 통해서 응답 내용을 수정할 수 있게 해주는 ASP.NET의 응답 필터링 기능 역시, 비 ASP.NET 콘텐츠를 대상으로도 동작할 수 있도록 향상되었습니다. 따라서, ASP.NET 필터링을 모든 서버 콘텐츠에 적용하거나 일부 원하는 유형의 콘텐츠들만을 대상으로 동작하도록 선택적으로 설치할 수 있습니다. 이 기능을 이용하면, 해당 콘텐츠가 ASPX 페이지인지 정적 파일인지 전혀 신경쓰지 않고도 사이트 응답에서 임의의 콘텐츠들을 대상으로 주입 또는 검열을 실시하는 필터링 기능을 작성할 수 있습니다.

요약

IIS 7과 ASP.NET의 통합은 ASP.NET의 모든 가능성을 활짝 열어주어 개발자로 하여금 쉽고 풍부한 기능의 ASP.NET과 .NET 프레임워크로 강력한 서버 구성 요소들을 작성할 수 있도록 해줍니다. 기존 응용 프로그램들을 위한 ASP.NET 통합 모드 활용에 대한 보다 상세한 내용은 How to Take Advantage of the IIS 7.0 Integrated Pipeline을 참고하시기 바랍니다. 그리고, 서버 확장을 위한 새로운 ASP.NET 구성 요소를 작성하는 방법에 관한 정보는 .NET 프레임워크로 IIS 7 모듈 및 헨들러 개발하기를 참고하시기 바랍니다.