[HTTP] 4. URL

URL 문법

URL로 모든 리소스를 찾을 수 있지만, URL 문법은 스킴에 따라서 달라진다. 단, 대부분의 URL은 일반 URL의 문법을 따르기에 서로 다른 스킴도 형태와 문법이 매우 유사하다. 여기서 말하는 대부분의 URL 스킴은, 일반적으로 아래의 9가지 문법을 따른다.

1. 스킴 : 서버에서 리소스를 가져오기 위해 사용해야 하는 프로토콜, 즉 방법.
2. 사용자 이름 : 몇몇 스킴은 리소스에 접근하기 위해 사용자 이름을 필요로 한다, 기본 값으로 “annoymous”를 가진다.
3. 비밀번호 : 사용자의 비밀번호를 가리키며, 사용자 이름에 콜론으로 이어서 기술한다.
4. 호스트 : 리소스를 호스팅하는 호스트 명이나 IP 주소.
5. 포트 : 리소스를 호스팅하는 서버가 열어 놓은 포트 번호, 많은 스킴이 기본 포트를 가지고 있다. HTTP는 80.
6. 경로 : 서버 내 리소스의 위치를 가리킨다.
7. 파라미터 : 입력 파라미터들을 기술하는 용도로 사용. 이름/값을 쌍으로 가지며, 세미콜론으로 구분하여 기술한다.
8. 질의 : 스킴에서 애플리케이션에 파라미터를 전달하는 용도로 쓰인다.
9. 프래그먼트 : 리소스의 조각이나 일부분을 가리킨다. URL의 끝에서 #으로 구분된다.

 

스킴 : 사용할 프로토콜

스킴 컴포넌트는 알파벳으로 시작해야 하고, URL의 나머지 부분들과 첫 번째 : 문자로 구분한다. 스킴 명은 대소문자를 구분하지 않는다.

 

호스트와 포트

애플리케이션이 인터넷에 있는 리소스를 찾으려면 호스팅하는 장비와, 그 리소스에 접근할 수 있는 서버가 어디에 있는지 알아야 한다. URL 호스트와 포트 컴포넌트는 그 두 가지 정보를 제공한다. 호스트는 인터넷 상의 호스트 장비를 가리킨다. 이는 호스트명이나 IP 주소로 되어 있다. 포트 컴포넌트는 서버가 열어놓은 네트워크 포트를 의미한다.

 

경로

리소스가 서버에서 어디에 있는지를 알려준다. 계층적 파일 시스템 경로 (UNIX의 파일 시스템의 파일 경로)와 유사하다. 각 경로 조각은 자체적인 파라미터 컴포넌트를 가질 수 있다.

 

파라미터

많은 스킴이 객체에 대한 호스트 및 경로 정보만으로는 리소스를 찾지 못한다. 어떤 포트를 열었는지, 사용자 이름과 비밀번호를 명시했는지 외에도, 더 많은 정보를 요구해야 할 때도 있다. 따라서 URL을 사용하는 애플리케이션이 리소스에 접근하려면 프로토콜 파라미터가 필요하다.

 

질의

TODO : 질의가 query를 말한 게 아닐까?

웹 데이터 베이스 게이트웨이에 질의하기 위해서 사용한다.

 

프래그먼트

리소스 안의 특정 절을 가리키기 위해서 사용한다. 예를 들어 텍스트 안에서 일정 부분만을 가리킬 때 사용된다. #으로 구분한다. 예컨대 특정 호스트의 tools.html#drills 라고 작성하였다면, tools.html에서 drills로 시작되는 구간으로 스크롤을 내린다.

 

단축 URL

웹 클라이언트는 몇몇 단축 URL을 인식하고 사용한다. 상대 URL은 리소스를 간결하게 기술하는 데에 사용할 수 있다. 많은 브라우저가, 사용자가 기억하고 있는 URL의 일부분을 입력하면 나머지를 자동으로 입력해주는 URL ‘자동 확장’ 기능을 지원한다.

 

상대 URL

URL은 상대 URL과 절대 URL로 나뉜다. 지금까지 본 것은 모두 절대 URL인데, 절대 URL은 찾고자 하는 리소스로 접근하기 위한 모든 정보를 가지고 있다. 하지만 상대 URL는 모든 정보를 가지고 있지 않다. 이는 ‘./’와 같이 현재 주소로부터, 와 같은 축약된 의미들을 사용하기 때문이다. 상대 URL은 URL의 일부거나, 또는 프래그먼트이다. 이를 사용함으로써 문서 집합의 위치를 옮기더라도 잘 동작할 수 있게 됐다. URL을 처리하는 브라우저 같은 애플리케이션은 상대 URL과 절대 URL을 상호 변환할 수 있어야 한다.

 

기저 URL

변환 단계에서의 첫 단계는 기저 URL (./이 의미하는 현재 위치)를 찾는 것이다. 이를 위한 방법은 여러 가지가 있는데, 아래에 서술한다.

• 리소스에서 명시적으로 제공 : 어떤 리소스들은, HTML 내에서 BASE 태그를 사용하여 명시하기도 한다.
• 리소스를 포함하고 있는 기저 URL : 특정 URL이 위와 같이 BASE 태그를 사용하지 않았다면, 그 페이지를 기저 url로 가정한다.
• 기저 url이 없는 경우 : 절대 URL로만 이루어져 있는 경우거나, 불운하게도 불완전하거나 깨진 URL일 수 있다.

 

URL 확장

• 호스트 명 확장 :휴리스틱만 이용하여 전체 호스트 명으로 확장한다. naver를 입력하면 자동으로 www와 .com을 붙여서 완성해준다.
• 히스토리 확장 : 과거에 방문했던 URL 기록을 저장하여 선택할 수 있게 해준다.

 

안전하지 않은 문자

안전한 전송이란 정보가 유실될 위험 없이 URL을 전송할 수 있다는 것을 의미한다. URL은 문자가 제거되지 않게 상대적으로 작고 안전한 알파벳만 포함하도록 허락한다. 또한 가독성을 위해서, 혹여 변화늘 통해서 보이지 않거나, 원칙적으로 사용 불가능한 문자가 나올 수 있다고 하더라도 일상적으로 사용하는 것을 금했다.

 

URL 문자 집합

보통 영어 중심으로 설정되어 있다. 역사적으로 많은 컴퓨터 애플리케이션들이 US-ASCII 문자 집합을 사용해왔다. 이는 문자를 서식화하고 신호를 주고 받기 위해서 7비트를 사용한다. (영어 말고도 몇몇 제어 문자를 표현할 수 있다.) 다만 URL 설계자들은 URL에 이스케이프 문자열을 쓸 수 있게 설계하였다. 이로써 특정 문자나 데이터들을 인코딩할 수 있게 함으로써 이동성과 완성도를 높였다.

 

인코딩 체계

안전한 문자 집합을 이용하는 경우 표현의 한계가 있다. 따라서 URL에서 안전하지 않은 문자들을 표현할 수 있는 인코딩 방식이 고안되었다. 인코딩은 안전하지 않은 문자를 % 기호로 시작하여 ASCII로 표현되는 두 개의 16진수 숫자로 이루어진 이스케이프 문자로 바꾼다.

 

문자 제한

몇몇 문자는 URL에서 특별한 의미로 예약되어 있다. 내용은 책 42P 참고.

 

좀 더 알아보기

사실 URL에 안전하지 않은 문자를 넣더라도 전송 프로토콜에서는 문제가 발생하지 않는다. 다만 이런 문자를 인코딩하지 않고 넣는 것은 개발자의 실수다. 이런 문자를 넣게 될 경우 다른 애플리케이션에서, 그 문자가 특수한 의미를 가지는 경우에 문제가 발생할 수 있다.