URI

통합 자원 식별자(Uniform Resource Identifier, URI)는 인터넷에 있는 자원을 나타내는 유일한 주소이다.

개요

통합 자원 식별자(Uniform Resource Identifier, URI)는 인터넷에 있는 자원을 나타내는 유일한 주소이다. URI의 존재는 인터넷에서 요구되는 기본조건으로서 인터넷 프로토콜에 항상 붙어 다닌다. 통합 자원 식별자(URI가)는 문자열 문자를 명확하게 식별하고 특정 자원을 균일성 있게 보장한다. 그래서 모든 URI는 사전정의 된 구문 규칙을 따르고 별도로 정의 된 계층적 이름 지정 체계를 통해 확장성 을 유지 한다. http:// 이러한 식별은 특정 프로토콜을 사용하여 네트워크를 일반적으로 월드 와이드 웹을 통해 리소스 표현과 상호 작용할 수있게 한다. 구체적인 구문관련 프로토콜을 지정하는 체계는 각 URI를 정의한다. 가장 일반적인 URI 형식은 URL(Uniform Resource Locator )이며, 비공식적 웹 주소 라고한다. URN( Uniform Resource Name )은 특정 네임 스페이스에서 리소스를 식별하기위한 메커니즘을 제공하여 URL을 보완하도록 디자인 된 경우이외에만 사용되며 일반적으로 거의 사용되지 않는다.

역사

URI와 URL은 역사를 함께 공유한다. 1994년 팀 버너스 리가 하이퍼텍스트를 제안하면서 하이퍼링크의 대상이 되는 자원을 대표하는 짧은 문자열로 URL의 개념을 암묵적으로 도입하였다. 당시 사람들은 이를 "하이퍼텍스트 이름"또는 "문서 이름"으로 불렀다. 향후 3년 반 동안 HTML, HTTP 및 웹 브라우저에 대한 월드 와이드 웹의 핵심 기술이 개발됨에 따라 리소스 주소를 제공하는 문자열과 단순히 리소스라는 이름의 문자열을 구분해야했다. URL과 URN 정의에 대한 토론에서 두 용어로 구현 된 개념은 단지 자원 식별의 기본적이고 지나치게 중요한 개념이라는 측면에 불과하다는 것이 분명해졌다. 1994 년 6월, IETF 는 URL과 URN의 존재를 인정한 최초의 의견 요청인 Berners-Lee의 RFC 1630을 출판했습니다. 가장 중요한 것은 Universal Resource Identifiers(예 : 정확한 구문과 의미가 체계에 따라 달라지는 URL 유사 문자열)에 대한 공식 구문을 정의한 것이다. 또한 RFC는 당시에 사용중인 URL 체계의 구문을 요약하려고 시도했다. 일반 URI와 절대 URI 참조 문법은 RFC 2396에 처음 정의되었다. 1998년 8월 출판되었으며,RFC 3986로 완성되어, 2005년 1월 출판되었다. Uri에 대 한 사양은 RFC 2396, RFC 2732, RFC 3986 및 RFC 3987을 게시 하 여는 Task Force IETF (Internet Engineering)에 나와 있다.

특징

URI에는 인트라넷 또는 인터넷에서 애플리케이션에 사용할 수 있는 리소스의 compact표현이다. URI는 속성 및 메서드 구문 분석, 비교 및 결합을 포함 하는 URI를 처리 하기 위한 클래스를 정의 한다. URI클래스 속성은 읽기 전용 이며 수정할 수 있는 개체를 만들어서 사용 한다. 그것이 UriBuilder 클래스이다.

요청 필터링(Request Filtering)과 URL Rewrite기술

요청 필터링은 IIS7에서 기본적으로 제공하는 보안 기능이다. 이전에는 URLScan 이라는 녀석의 기능과 비슷하기도 하다. 간단히 이녀석이 수행하는 기능은 IIS의 내장된 보안 기능으로 특정 URL이 들어올 경우 필터링, 특정 파일 확장자(Extension)을 요청할 경우 필터링, ASP.NET의 App_code와 같은 폴더에 대한 접근 필터링, HTTP 헤더의 길이 제한, HTTP의 특정한 verb에 대한 필터링 등이 가능하다. 아울러, 요청 필터링은 이러한 보안 필터링 기능을 웹사이트단위 또는 웹서버 전체에 대해서 적용 가능하다. 요청 필터링과 URL Rewrite의 비슷한점은 두가지 기능 모두 URL이나 HTTP Request에 대한 보안 기능을 적용 가능하다는 점에서는 유사하다. 하지만 아래와 같은 차이점이 있다. 요청필터링은 순수한 보안 목적으로 제작되었지만 URL Rewrite는 범용적인 URL 처리를 위한 목적으로 제작되었으며, URL Rewrite가 제공하는 보안 기능은 여러가지 기능들 중의 일부이다. 성능 측면에서는 두가지 기술 모두 영향을 줄 정도로 부하가 높지는 않다. 하지만, URL Rewrite의 경우 정규표현식을 이용하기 때문에 요청 필터링 보다는 약간 더 높은 시스템 리소스를 이용하게 된다. 요청 핕터링은 문자열에 대한 추출 작업만을 진행해 비교하기 때문에 시스템 리소스를 상대적으로 덜 사용하게 된다. URL Rewrite와 요청 핕터링은 각각의 목적에 맞는 보안 기능들이 있으며 필요할 경우 두 기능을 조합해서 이용도 가능하다.

참고자료

• 〈통합 자원 식별자〉, 《위키백과》
• 〈균일 한 자원 식별자〉, 《위키피디아》
• 김대우,〈요청 필터링과 URL Rewrite〉, 《마이크로소프트 블로그》, 2009-10-14