메뉴 건너뛰기


Developer > Network

HTTP 제3장. URL(Uniform Resource Locators)

2013.11.12 07:19

푸우 조회 수:7438

제3장. URL(Uniform Resource Locators)
 
 
1. URI, URL, URN, URC의 정리
 
URI(Uniform Resource Identifiers), URL(Uniform Resource Locators), URN(Uniform Resource Names), URC(Uniform Resource Characteristics)은 서비스나 통신망 상의 데이터들의 위치를 구분하고 지정하기 위해 사용하는 용어들입니다.
영어를 해석하면 URI는 자원을 식별하는 공통된 형식이라는 뜻이 될 것이고... URL은 자원의 위치를 나타내는 공통된 형식, URN은 자원을 지칭하는 공통된 형식, URC는 자원은 특성을 나타내는 공통된 형식이라고 할 수 있겠습니다.
 
IETF(Internet Engineering Task Force)에서 정의한 용어들인데 내용이 비슷비슷 한것 같습니다.
 
HTTP를 공부하기 위해서는 URL정도만 알면 되겠지만... 공부하는 김에 다 알아 봅시다.
 
URI는 URL과 URN 그리고 URC가 합쳐진 개념입니다. 우리가 관심있는 URL은 URI의 서브셋으로 보면 되겠지요.
 
먼저 URC는 자원의 메타정보로서 '속성/값'으로 되어 있습니다. 예를 들면 인터넷상의 어떤 문서에 저자, 서명, 주제, 출판사와 같은 정보를 URC로 표시할 수 있습니다. 뭐 잘 쓰이지는 않는 것 같습니다.
 
URN은 자원의 유일한 식별기호를 의미합니다. URN에는 자원의 위치정보는 포함되지 않으며 전세계적으로 동일한 자원에는 유일한 URN이 영구적으로 부여됩니다. 예를 들면 ISBN, ISO식별기호와 같은 것들을 들 수 있을 것입니다. 어떻게 명명할 것인지는 명명기관이 책임을 질 일이지만 중요한 것은 부여된 URN은 동일한 의미(자원의이름)을 가져야 한다는 것입니다.
다음은 URN의 사용예입니다.
예) urn:isbn:1234567890
     urn:uuid:1abc23d4-56ef-78a9-b0c1-2345d678e9f0
 
마지막으로 우리가 자주 사용해 봤던 URL입니다. URL은 http://bbs.nicklib.com/index.html 과 같은 형태를 이야기 합니다.
URL은 프로토콜 정보, 호스트의 도메인명 그리고 자원의 경로로 표시됩니다.
HTTP에 사용하는 URL에 대해서는 다음 절에서 따로 좀 더 자세히 이야기 하겠습니다.
 
 
2. HTTP URL
 
HTTP URL은 다음과 같은 형태로 표시될 수 있습니다.
 
<scheme>://[name[:password]@]<host>[:port][[abs_path]?query][#fragment]
 
- Scheme
scheme은 필수 항목으로 프로토콜의 명칭을 사용하게 됩니다. 예로 ftp, gopher, mailto와 같은 것을 사용할 수 있습니다. 우리가 공부하는 HTTP의 경우는 "http"만 사용할 수 있습니다.
<주의> Scheme는 대소문자 구분이 없습니다.
- Name:Password
나중에 살펴보겠지만 URL에서 Basic 인증을 사용할때 인증 정보로 사용자 정보와 암호를 URL에 포함할 수 있습니다.
- Host
host는 필수 항목입니다. 여기에 올 수 있는 항목은 인터넷 호스트 도메인 이름이나 IP주소가 올 수 있습니다.
<주의> Scheme는 대소문자 구분이 없습니다.
- Port
port가 생략되면 HTTP의 기본 Port인 80 이 사용되게 됩니다. 달리 말하면 HTTP서비스의 TCP Port가 80포트가 아닌 경우는 반듯이 사용할 Port번호를 명시하여야 합니다.
- Abs_Path
자원의 절대 경로를 명시합니다. 자원의 절대 경로가 지정되지 않으면 "/"인 것으로 합니다.
- Query
요청하는 자원이 CGI와 같이 동적으로 변화하는 자원인 경우 "?"를 붙인 후 query문자열을 적을 수 있습니다. query 문자열은 "변수=값"형식을 하나의 파라메터로 여러 파라메터를 사용할 경우 "&"문자로 각각의 파라메터를 연결하면 됩니다.
- Fragment
Fragment는 요청하는 자원의 특정 위치를 지정하는 용도로 사용됩니다. 하지는 이 부분은 client가 처리하여야 한다. 즉, Web서버에서는 이부분이 무시되어야 합니다.
 
HTTP URL을 모두 사용하는 예를 들면 http://nicholas:1234@bbs.nicklib.com:8080/abc/def.cgi?id=1&code=AB#top 와 같이 될 수 있겠네요.
 
URL에 안전하지 못한 문자들이 있는 경우 이를 %HEXHEX 형태로 표기해야 합니다.
또한 예약된 문자들이 본래의 의미외에 사용될 경우도 %HEXHEX 형태로 표기해야 합니다.
 
예약된 문자들로는 ";" | "/" | "?" | ":" | "@" | "&" | "=" | "+" | "$" | "," 을 이야기 하며 안전하지 못한 문자란 제어문자(0~31, 127) | 공백 | " | # | % | < | > 그리고 숫자, 영문자 범위 밖의 문자들을 이야기 하며 안전한 문자란 "$" | "-" | "_" | "." 문자들을 이야기 합니다.
 
또한, HEX란 16진수를 의미합니다. 한 바이트의 숫자는 2개의 16진수로 표시할 수 있습니다. (00~FF까지) 고로 위의 말은 예약문자인 @를 query 문자열 같은 곳에 사용할려면 @문자의 ASCII코드값인 64에 해당하는 16진수인 40으로 %를 붙여 사용해야 한다는 것입니다. 16진수도 대소문자 구분이 없습니다.
 
또한 query문자열 중 값부분에 공백문자가 있다면 "+" 문자로 대체되어야 합니다. 하지만 "+"자체를 사용해야 할 경우 구현된 Application에 따라 문제가 발생할 수 있기 때문에 %20을 사용할 것을 더 권장합니다.
 
HTTP/1.1에서는 URI의 길이에 제한을 두지는 않습니다. 하지만 옛날 client나 프록시는 255byte이상을 처리 할 수 없는 경우가 있으므로 주의해서 사용하라고 합니다. 또한, Web 서버에서도 client로 부터 전달되어온 URI가 너무 길어서 처리할 수 없는 경우 414 (Request-URI Too Long) 상태를 전달해야 한다고 RFC에서 이야기 합니다.
 
예로 다음의 URL들은 모두 같은 것으로 여겨져야 합니다.
 
Creative Commons License
Creative Commons License이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.
Copyright 조희창(Nicholas Jo). Some rights reserved. http://bbs.nicklib.com