디자인과 관련하여 사용자가 결정해야 하는 더 중요한 사항 중 하나는 응용 프로그램이 서로 다른 클라이언트 기능을 처리하는 방식입니다. 예를 들어 사용자에게 가장 중요한 문제 중 하나는 연결 속도입니다. 응용 프로그램이 이 속도를 파악할 수 있다면 이 속도에 맞추기 위해 응답을 조정할 수 있습니다. 응용 프로그램이 현재 연결 속도를 알 수 있는 유일한 길은 클라이언트가 이 정보를 요청의 일부로 포함하는 경우입니다.
사용자는 클라이언트쪽이나 서버쪽에서 클라이언트 기능 문제를 해결할 수 있습니다. 클라이언트쪽 솔루션은 아래 그래픽에서처럼 동적 HTML(DHTML)에 의존하여 클라이언트의 현재 구성 설명을 요청의 일부로 포함시킵니다.
이런 접근법의 장점에는 다음이 포함됩니다.
클라이언트쪽 스크립팅이 불가능한 상황이 있습니다. 예를 들어 인터넷에 제공된 응용 프로그램은 클라이언트가 스크립팅을 지원하는 것을 보장할 수 없습니다. 즉 일부 클라이언트에서는 응용 프로그램이 실패할 수도 있는 것입니다. 또한 클라이언트가 보안상의 이유로 스크립팅을 허용하지 않는 네트워크에 상주하기 때문에 클라이언트쪽에서 서버쪽 리소스를 액세스할 수 없을 수도 있습니다.
Browser Capabilities 구성 요소에 따라 서버쪽 접근법이 달라집니다. 이 구성 요소는 요청에 포함된 사용자 에이전트 HTTP 헤더를 읽어서 클라이언트의 기능을 파악합니다. IIS 3.0과 4.0의 Browser Capabilities 구성 요소는 정적 목록에서 클라이언트 기능을 조회하여 파악하였습니다. 다음 도표는 이벤트 순서를 보여 줍니다.
목록이 이전 것일 경우 응용 프로그램 디자이너가 이 접근법을 사용하기가 어렵습니다. 더 중요한 것은 이 기술이 클라이언트 기능에서 구성할 수 있는 측면을 포괄하지 못하고 또 요청되었을 당시에 실제 사용 가능했던 수단을 제공하지 못한다는 것입니다.
IIS 5.0에서는 Browser Capabilities 구성 요소가 이와 같은 초기 디자인 한계를 극복하도록 개선되었습니다. Browser Capabilities 구성 요소는 그 기능을 설명하는 쿠키를 반환하는 클라이언트의 개별 요청에 맞게 수정할 수 있습니다. 또한 .asp 파일에 대한 처음 요청에 쿠키가 포함되어 있지 않으면 사용자가 클라이언트에서 실행될 스크립트에 쿠키를 작성하도록 콜백할 수 있습니다. 다음 그림은 이벤트 순서를 보여 줍니다.
이와 같이 Browser Capabilities 구성 요소가 개선됨으로써 서버쪽 솔루션에 대한 다른 대안이 마련됩니다. 이 기술은 특수 상태 코드를 사용하여 요청이 올 때 이 코드에 쿠키가 포함되어 있지 않으면 클라이언트에게 콜백합니다. 사용자는 .asp 파일의 첫째 줄에 특수 메타 태그를 넣어서 상태 코드를 작성할 수 있습니다. 예를 들면 다음과 같습니다.
<!-- METADATA TYPE="Cookie" NAME="BrowsCap" SRC="sendcook.htm" -->
위코드는 IIS가 Internet Explorer 5에특수상태코드인 HTTP 449 상태코드를보내도록합니다. 그런다음 Internet Explorer 5.0에게 Sendcook.htm에있는스크립트를실행하도록지시합니다. 이스크립트가실행되면클라이언트기능을설명하는쿠키가만들어집니다.서버가이쿠키를받으면이쿠키와 Browser Capabilities 구성요소를같이사용하여클라이언트에응답을돌려보내는방법을결정합니다.
중요 Server.Transfer 또는 Server.Execute 메서드를 사용하여 리디렉션 결과로 클라이언트가 요청한 파일에 METADATA 메타 태그가 있으면 IIS는 메타 태그를 무시합니다. 그러나 실제로 리디렉션이 포함된 파일에 있는 METADATA 메타 태그는 정상적으로 처리됩니다.
이 기능의 사용 방법에 대한 자세한 내용은 쿠키에서 Browser Capabilities 검색을 참조하십시오.
DHTML 클라이언트 기능에 대한 자세한 내용은 MSDN Online에서 DHTML 참조 정보를 참조하십시오. 새 Client Capabilities 구성 요소 기능의 예제는 Browser Capabilities 구성 요소 및 ASP 예제를 참조하십시오.