2장 URL과 리소스 [HTTP 완벽가이드]

이 장에서 다루는 내용들

• URL 문법, 여러 URL 컴포넌트가 어떤 의미를 가지며 무엇을 수행하는지
• 여러 웹 클라이언트가 지원하는 상대 URL과 확장 URL 같은 단축 URL에 대해서
• URL의 인코딩과 문자 규칙
• 여러 인터넷 정보 시스템에 적용되는 공통 URL 스킴
• 기존 이름은 유지하면서 객체들을 다른 장소로 옮기는 것을 가능하게 해주는 URN을 포함한 URL의 미래

2.1 인터넷의 리소스 탐색하기

1장에서 URL의 구조를 간단히 설명한 적있다.

URL에는 스킴, 호스트, 패스, 쿼리, 프래그먼트가 구성 요소지만, 모두 포함하지 않아도 된다.

스킴, 호스트, 패스 정도가 URL의 항상 포함해야 하는 것들이다.

mailto:tamm@google.com

ftp:ftp.tamm.com/video/bts-01.avi

rtsp://www.tamm.com:43/interview/bts-02.avi

2.1.1 URL이 있기 전 암흑의 시대

웹과 URL이 있기 전에는 각종 포맷과 프로토콜에 대해 각자 자기만의 중구난방의 리소스 경로를 가졌다.

2.2 URL 문법

URL을 더 깊이 들어가면,,

://:@:/;?#

의 더 빡센 구조를 갖는다. 사용자 정보와 파라미터가 새롭게 등장했다. 사용자 정보는 보안적인 측면에서 잘 사용하지 않는 면이 있는 것 같다. 파라미터의 경우는 거의 확용하는 것을 볼 수 없었는데, 자세한 사용예는 뒤에 다루도록 한다. 어쨋든 REST Full한 구조를 갖기 때문에 parameter의 활용도는 낮아 보인다.

2.2.1 스킴: 사용할 프로토콜

2.2.2 호스트와 포트

호스트에는 호스트명이나 IP주소로 제공한다. 포트는 항상 필요하지만 생략할 수 있다. 스킴에 따라 기본 포트로 적용된다. HTTP는 80, HTTPS는 443 등이다.

2.2.3 사용자 이름과 비밀번호

처음 알았는데, 입력하지 않으면 브라우저 차원에서 임의의 값을 넣어서 사용한다고 한다. 사용자 이름의 기본값으로 'anonymous'를 사용하고 비밀번호의 경우 브라우저 마다 다른데, 크롬은 chrome@example.com을 넣는다고 한다.

2.2.4 경로

경로의 경우 unix의 경로와 비슷하게 설계되었다고 한다.

2.2.5 파라미터

파라미터는 나도 처음 알게되었다.

http://tamm.com/food;type=japan/porkcutlet;topping=cheese

위 예시처럼 path 사이사이에 파라미터를 여러개 등록하는 것도 가능하다.

2.2.6질의 문자열

주로 검색 질의로 많이 사용한다. &로 구분하여 여러값을 넣을 수 있다.

2.2.7 프래그먼트

유일하게 서버로 전달하지 않는 값으로, 브라우저 내부에서 사용하는 문맥이다. 이를 응용하여 SPA이 개발한다고 한다.

2.3 단축 URL

2.31 상대 URL

하나의웹페이지를 제공하는 서버가 있다고 하면 이 서버에서 다른 값으로 별도로 제공하지 않으면, 스킴과 호스트, 포트 모두 동일 할 것이다. 이 세개를 합쳐서 base 또는 baseURL이라고 한다. 웹 페이지 내에서 baseURL을 포함하지 않고 path 이후 만 전달해도 baseURL을 기반으로 하나의 URL을 완성 시킬 수 있다. 이렇게 하면 유연하게 구성할 수 있다.

2.3.2 URL 확장

별건 아니고 브라우저에서 URL 자동완성 기능을 생각하면된다. www 같은 서브 네임을 자동으로 입력해준다던가, 어떤 단어만 입력해도 history에서 hit된 것들로 후보지를 보여준다던가 하는 것 말이다. 크롬의 경우는 URL에 단어를 입력하면 단어를 검색하는 크롬 검색 URL을 만들어서 처리하는 식 말이다.

2.4 안전하지 않는 문자

URL에서 특정 목적으로 사용하는 값과 안전하지 않는 값이 있다. 예를들면 :은 스킴 다음에 나오는 값, ?는 쿼리를 나내는 값이므로 URL안에서 다른 용도로 사용할 수 없다.

이 밖에 대부분의 문자는 안전하지 않은 문자로 분류된다. 그 이유는 URL이 메일이나 ftp등도 포함하는 넓은 개념이기 때문이다. 예를들어 메일에서 허용하지 않는 값을 URL에서 사용하면 URL은 메일 주소를 올바르게 처리할 수 없다. 우리는 메일에서만 문제가 발생한다고 하더라도 이런 값은 장기적으로 문제를 일으킬 수 있다. 이런 값들을 안전하지 않은 값이라 한다.

우리는 서비스의 안전성을 위해서 항상 안전한 값으로 변경해서 처리해야 한다. 안전한 값이라고 하면 영어랑 몇몇 기호들이라고 생각하면 된다.

2.4.1 URL 문자 집합

기본적으로 컴퓨터 시스템의 기본 문자 집합이 영어로 설정되어 있기 때문에 영어랑 키보드에 프린팅된 문자들로 구성 되어있다. 이 외의 문자를 포함할 때 인코딩하여 사용한다.

2.4.2 인코딩 체계

URL에서 안전하지 않는 문자를 다른 문자로 치환하는 것을 URL인코딩이라고 하는데 스킴을 구분하는 :은 %3a로 인코딩 되는 식이다.

2.4.3 문자 제한

2.4.4 좀 더 알아보기

어떤 요청을 받은 초기 어플리케이션에서 안전하지 않은 문자를 인코딩 하지 않은 것은 실수다. 서버에서도 안전하지 않은 문자가 있는지 검증해야 하는 것 맞다.

2.5 스킴의 바다

여러 스킴의 예시를 적어놨다. 아까 URL 구조를 소개 했는데, 스킴마다 모든 구성요소를 다 가지지 않고 스킴에 따라 조금씩 다르게 갖는다.

://:@:/;?#

ftp://anonymous:tamm%40tammo.com@tamm.com/files/bts-01.avi

news:rec.arts.tarktrek

http같은 스킴은 위에서도 언급했고, ftp에 %40은 @ 문자가 인코딩 된 것을 알 수 있다. 또 news 스킴은 호스트가 없는 형태다. 잘 모르겠다. (관심 없음)

2.6 미래

URL은 매우 유용하고 널리 사용된다. 그러나 리소스의 위치가 변경되면 URL을 찾을 수 없는 등의 문제가 있다. 이를 위해 URN의 개념이 도입되었지만, URL을 대체하는 것은 어려워 보인다.

2.6.1 지금이 아니면, 언제?

URL은 초보자가 고통을 받고 있지만, URL은 당분간 계속 사용될 예정이다.