2장 URL과 리소스
1장(HTTP 개관)에서 URL의 구조를 알아보았다. 다시 한번 간단히 정리하자면 스킴(Scheme)은 웹 클라이언트가 서버 리소스에 어떻게 접근하는지를 알려주고, URL의 두번째 부분은 서버의 위치로써 웹 클라이언트가 리소스가 어디에 호스팅 되어있는지를 알려준다. 마지막 부분인 리소스의 경로는 서버에 존재하는 로컬 리소스들 중에서 요청받은 리소스가 무엇인지를 알려준다.
URL 스킴 문법
1 | <스킴>://<사용자명>:<비밀번호>@<호스트>:<포트>/<경로>;<파라미터>?<질의>#<프래그먼트> | cs |
스킴 | 알파벳으로 시작하고 대소문자를 구별하지 않는다. |
|
사용자명, 비밀번호 | 리소스 접근을 위한 사용자명과 비밀번호. 보통 ftp 이용시 많이 사용한다. |
|
호스트 | 리소스를 호스팅하는 서버의 호스트명 혹은 IP 주소. |
|
포트 | 서버가 열어놓은 네트워크 포트로 HTTP 내부적으로 TCP 프로토토콜을 사용하기 때문에 80번 포트를 기본적으로 사용한다. |
|
경로 | 해당 리소스의 경로. |
|
파라미터 | URL을 사용하는 애플리케이션이 리소스에 접근하려면 프로토콜 파라미터가 필요한데, 프로토콜 파라미터가 없으면 서버는 해당 요청을 잘못 처리하거나 처리하지 않을 것이다. URL의 파라미터 컴포넌트는 애플리케이션이 서버에 정확한 요청을 하기위해 필요한 입력 파라미터를 받는데 사용한다. |
|
질의 문자열 | 애플리케이션에 전달할 파라미터를 키=값 형태로 전달한다. URL 끝에 '?'를 붙여서 시작하고 질의할 파라미터간 구분은 '&'로 한다. |
|
프래그먼트 | 리소스 내의 특정 부분을 가리킬 수 있는 컴포넌트이다. HTTP 서버는 객체 일부가 아닌 전체만을 다루기 때문에 클라이언트는 서버에 프래그먼트를 전달하지 않는다. 브라우저가 서버로부터 전체 리소스를 내려받은 후 프래그먼트를 사용해 리소스의 일부를 보여준다. |
단축 URL
절대 URL
리소스에 접근하는데 필요한 모든 정보를 가진다.
상대 URL
모든 정보를 가지고 있지는 않고 리소스에 접근하기 위한 모든 정보를 얻기 위해서 기저(base)라는 다른 URL을 사용해야한다.
기저 URL
기저 URL은 상대 URL의 기준이 된다.
- 기저 URL 취득 방법
1. 리소스에서 명시적으로 제공 : HTML 문서 안에서 <BASE> 태그로 기저 URL을 지정한다.
2. 리소스를 포함하고 있는 기저 URL : 상대 URL이 기저 URL이 명시되지 않은 리소스에 포함된 경우 해당 리소스의 기저 URL
3. 기저 URL이 없는 경우 : 보통 절대 URL만으로 이루어져 있음.
URL 인코딩
URL에서의 사용할 수 있는 문자의 한계를 넘기 위해 인코딩 방식이 고안되었다. 안전하지 않은 문자를 '%'로 시작해 ASCII 코드로 표현되는 두 개의 16진수 숫자로 이루어진 이스케이프 문자로 변환하는 것이다.
예를 들어, 요청하는 문서가 'document name.html' 일 때 변환된 URL은 http://logical-code.tistory.com/document%20name.html 이다.
그리고 몇몇 문자열은 URL에서 예약어로 쓰이고 있기 때문에 이스케이프 문자로 변환할 필요가 있다.
|
문자 |
선점 및 제한 |
|
% |
인코딩된 문자에 사용할 이스케이프 토큰으로 선점 |
|
/ |
경로 컴포넌트에 있는 경로 세그먼트를 나누는 용도로 선점 |
|
. |
경로 컴포넌트에서 선점 |
|
.. |
경로 컴포넌트에서 선점 |
|
# |
프래그먼트의 구획 문자로 선점 |
|
? |
질의 문자열의 구획 문자로 선점 |
|
; |
파라미터의 구획 문자로 선점 |
|
: |
스킴, 사용자 이름/비밀번호, 호스트/포트의 구획 문자로 선점 |
|
$ , + |
선점 |
|
@ & = |
특정 스킴에서 특벌한 의미가 있기 때문에 선점 |
|
{ } | ~ [ ] ' |
게이트웨이와 같은 여러 전송 에이전트에서 불안전하게 다루기 때문에 제한 |
|
< > " |
안전하지 않음 |
|
0x00-0x1F, 0x7F |
제한됨 |
|
> 0x7F |
제한됨 |
'🚽 Deprecated > HTTP 완벽가이드' 카테고리의 다른 글
4장 : 커넥션 관리 (0) | 2019.08.25 |
---|---|
1장 : HTTP 개관 (0) | 2018.12.16 |