URI (URL + URN)
URL vs URN
- URL:리소스가 어디 있는지 설명해 리소스 식별
- URN: 현재 그 리소스가 어디에 존재하든 상관없이 이름만으로 리소스를 식별
URL 불러오는 예시
http://www.jjae.com/profile/index.html이라는 url을 불러옴
http는 URL의 scheme으로 웹 클라이언트가 리소스에 어떻게 접근하는지 알려줌www.jjae.com은 서버의 위치로 리소스가 어디에 호스팅 되어 있는지 알려줌profile/index.html은 리소스의 경로로 서버에 존재하는 로컬 리소스들 중에 요청받은 리소스가 무엇인지 알려줌
URL 문법
<스킴>://<사용자 이름>:<비밀번호>@<호스트>:<포트>/<경로>;<파라미터>?<질의>#<프래그먼트>
스킴: 사용할 프로토콜
- 주어진 리소스에 어떻게 접근하는지
- URL을 해석하는 애플리케이션이 어떤 프로토콜을 사용하여 리소스를 요청해야하는지 알려줌
- 스킴명은 대소문자 가리지 않음 (
http://www.jjae.com===HTTP://www.jjae.com)
호스트와 포트
- 호스트: 접근하려고 하는 리소스를 가지고 있는 인터넷상의 호스트 장비 가리킴 (호스트명 or ip주소)
- 포트: 서버가 열어놓은 네트워크 포트를 가리킴
사용자 이름과 비밀번호
- 자신이 가지고 있는 데이터에 접근 허용 위해 이름과 비밀번호 요구
- 애플리케이션이 FTP와 같이 사용자 이름과 비밀번호를 요구하는 URL 스킴을 사용한다면, 그 값들이 삽입되어 있지 않을 경우 기본 사용자 이름과 비밀번호 값을 넣어놓을 것임
경로
리소스가 서버의 어디에 있는지 알려줌
파라미터
- 애플리케이션이 서버에 정확한 요청을 하기 위해 필요한 입력 파라미터를 받음
- 이름/값 쌍 리스트로 URL 나머지 부분들로부터
;문자로 구분하여 기술 - 각 경로 조각은 자체 파라미터를 가질 수 있음
http://www.jjae.com/profile;photo=true/index.html;graphics=true
질의 문자열
- 요청받을 리소스 형식의 범위를 좁히기 위해 질문이나 질의를 받을 수 있음
- 게이트웨이를 가리키는 URL의 경로 컴포넌트와 함께 전달하고 있음
(게이트웨이: 다른 애플리케이션에 접근하려고 할 때 거치는 통로) &로 나뉜이름=값쌍 형태
프래그먼트
- 리소스의 특정 부분을 가리킬 수 있도록 프래그넌트 컴포넌트 제공
(URL은 HTML 문서에 있는 특정 이미지나 일부분을 가리킬 수 있음) - URL 오른쪽에
#문자에 이어서 옴 - HTTP 서버는 일부가 아닌 전체만 다루기 때문에 클라이언트는 서버에 프래그먼트를 전달하지 않음
- 브라우저가 서버로부터 전체 리소스를 내려받은 후, 프래그먼트를 사용해 보고자하는 리소스의 일부를 보여줌
단축 URL
상대 URL과 절대 URL
- URL은 상대 URL과 절대 URL
- 절대 URL은 리소스에 접근하는데 필요한 모든 정보 가지고 있음
- 상대 URL은 모든 정보를 담고 있지는 않고, 필요한 모든 정보를 얻기 위해서는 base URL이라고 하는 다른 URL을 사용해야 함
- 상대 URL을 사용하면 리소스 집합(HTML 페이지 등)을 쉽게 변경할 수 있음, 문서 집합의 위치를 변경하더라도 새로운 base URL에 의해 해석될 것
상대 URL을 절대 URL로 변환하기
- 경로는
./hammers.html, base URL은http://www.joes-hardware.com/tools.html - scheme이 비어있기에 base URL의 스킴을 상속 받음(
http) - 적어도 한 개의 컴포넌트 비어 있지 않음 => 호스트와 컴포넌트를 상속 받음
- 상대 URL 컴포넌트와 상속받은 컴포넌트(scheme:
http, 호스트:www.joes-hardware.com)를 합치면 새로운 절대 URLhttp://www.joes-hardware.com/hammers.html얻음
URL 확장
호스트명 확장
- 주소 입력란에
naver를 입력하면 브라우저는 호스트명에 자동으로www,.com을 붙여서www.naver.com을 만듦 naver라는 단어를 포함한 사이트를 찾지 못하면 확장을 포기하기 전에 몇가지의 URL을 추가적으로 제시- 프락시와 같은 다른 HTTP 애플리케이션에 문제를 발생시킬 수 있음
히스토리 확장
- 과거에 사용자가 방문했던 URL의 기록을 저장해 놓는 것
- URL을 입력하면 입력된 URL의 앞 글자들을 포함하는 완결된 형태의 URL을 선택
안전하지 않은 문자
URL 문자 집합
- URL이 특정 이진 데이터를 포함해야 하는 경우 등을 지원하기 위해, URL 설계자들은 URL에 이스케이프 문자열을 쓸 수 있게 설계
인코딩 체계
- 안전한 문자 집합을 이용하는 경우, 그 표현의 한계를 넘기 위해 URL에 있는 안전하지 않은 문자들을 표현할 수 있는 인코딩 방식 고안
- 인코딩은 안전하지 않은 문자를
%로 시작 - ASCII 코드로 표현되는 두 개의 16진수 숫자로 이루어진 이스케이프 문자로 바꿈
문자 제한
- 몇몇 문자는 URL 내에서 특별한 의미로 예약
- URL에서 예약된 문자들은 본래의 목적이 아닌 다른 용도로 사용하려면, 그 전에 인코딩해야 함
| 문자 | 선점 및 제한 |
|---|---|
| % | 인코딩된 문자에 사용할 이스케이프 토큰으로 선점 |
| / | 경로 컴포넌트에 있는 경로 세그먼트를 나누는 용도로 선점 |
| . | 경로 컴포넌트에서 선점 |
| .. | 경로 컴포넌트에서 선점 |
| # | 프래그먼트의 구획 문자로 선점 |
| ? | 질의 문자열의 구획 문자로 선점 |
| ; | 파라미터의 구획 문자로 선점 |
| : | 스킴, 사용자이름/비밀번호, 호스트/포트의 구획 문자로 선점 |
| $ , + | |
| @ & = | 특정 스킴에서 특별한 의미가 있기 때문에 선점 |
| {} ~ | 게이트웨이와 같은 여러 전송 에이전트에서 불완전하게 다루기 때문에 제한 |
| <> " | 안전하지 않음, URL 범위 밖에서 역할이 있는 문자기 때문에 반드시 인코딩 필요 |
출처
HTTP 완벽 가이드
