1. 인터넷의 리소스 탐색하기
URL을 이용해 사용자들은 수십억개의 리소스를 찾고 서로간 공유가 가능하며, HTTP 및 다른 프로토콜을 통해 접근 가능하다. 따라서 인터넷에 있는 어떤 리소스든 가리킬 수 있다.
URL을 사용하면 리소스를 일관된 방식으로 지칭 할 수 있다. 대부분의 URL은 스킴://서버위치/경로 구조로 이루어진다.
예를 들어 http://www.example.com/first/file.html 이라는 URL이 있을 때
http (스킴) : 웹 클라이언트가 리소스에 어떻게 접근하는지
www.example.com (서버의 위치) : 리소스가 어디에 호스팅 되어있는지
/first/file.html (경로) : 서버에 존재하는 로컬 리소스들 중 요청받은 리소스가 무엇인지
2.URL 문법
URL문법은 스킴에 따라서 달라지지만 일반적으로 9개 부분으로 나뉜다.
<스킴>://<사용자이름>:<비밀번호>@<호스트>:<포트>/<경로>;<파라미터>?<질의>#<프래그먼트>
이 모든 컴포넌트를 가지는 URL은 거의 없다.
2.1 스킴 : 사용할 프로토콜
URL을 해석하는 애플리케이션이 어떤 프로토콜을 사용해 리소스를 요청해야 하는지
<특징>
- 알파벳으로 시작
- 나머지 부분과
:로 구분 - 대소문자를 가리지 않음
요즘 기본으로 쓰이는 HTTPS는 HTTP의 커넥션의 양 끝에 암호화하기 위해 넷스케이프에서 개발한 보안소켓계층(SSL)을 사용한다. HTTPS의 기본 포트 번호는 443이다.
2.2 호스트와 포트
인터넷에 있는 리소스를 찾기 위해선 리소스를 호스팅하고 있는 장비와 그 장비 내에서 리소스에 접근할 수 있는 서버가 어딨는지 알아야한다. URL의 호스트 컴포넌트와 포트 컴포넌트가 위 정보를 제공해준다.
호스트 컴포넌트 : 접근하려고 하는 리소스를 가지고 있는 인터넷상의 호스트 장비
포트 컴포넌트 : 서버가 열어놓은 네트워크 포트
2.3 사용자 이름과 비밀번호
FTP 프로토콜과 같이 사용자 이름과 비밀번호를 필요로 하지만 사용자 이름과 비밀번호를 입력하지 않는 경우, 기본값으로 입력된다. 사용자 이름의 기본값은 anonymous 비밀번호의 기본값은 브라우저마다 가지고 있는 기본값 이다. 크롬은 chrome@example.com을 넣는다고 한다.
하지만 최근 크롬에서는 FTP 프로토콜을 지원하지 않고 있어 사용을 원한다면 직접 설정을 변경해주어야 한다.
2.4 경로
계층적 파일 시스템 경로와 유사한 구조를 띄며, 리소스가 서버의 어디에 있는지 알려준다.
2.5 파라미터
URL을 사용하는 애플리케이션이 리소스에 정확하게 접근하려면 프로토콜 파라미터가 필요하다. 파라미터 컴포넌트는 애플리케이션 서버에 정확한 요청을 하기 위해 필요한 입력 파라미터를 받는데 사용된다. 파라미터의 시작은 ; 으로 구분짓는다. www.example.com;type=a
2.6 질의 문자열
웹 데이터베이스 게이트웨이에 질의 하기 위해 사용된다. 질의(쿼리)의 시작은 ? 로 구분짓는다. 여러 질의를 한번에 보내고 싶다면 각 질의를 & 로 구분한다. www.example.com?item=0415
2.7 프래그먼트
리소스의 특정 부분을 가르킬 수 있도록 한다. 예를 들어 URL은 HTML 문서에 있는 특정 이미지나 일부분을 가리킬 수 있다. HTTP 서버에서는 리소스를 객체의 일부가 아닌 전체로 다루기 때문에 리소스를 쪼갤 수 없다. 따라서 클라이언트는 서버에 프래그먼트를 전달하지 않는다.
3. 단축 URL
3.1 상대 URL
절대 URL은 리소스에 접근하는데 필요한 모든 정보를 가지고 있다. 이와 달리 상대 URL은 프래그먼트이거나 URL 일부만 작성되며 기저 URL을 이용해 사용된다. 주로 현재 속한 문서의 URL을 기준으로 상대 경로가 해석 된다.
기저 URL
상대 경로를 절대 경로로 변환하는 첫번째 단계인 기저 URL을 찾는 방법
상대 참조 해석하기
상대 URL을 절대 URL로 변환하기 위한 다음 단계는 상대 URL과 기저 URL을 각각의 컴포넌트 조각으로 나누는 것 (URL 파싱)
3.2 URL 확장
호스트명 확장
입력한 호스트명을 전체 호스트명으로 확장 ex) yahoo 검색 시, www.yahoo.com으로 자동 완성
호스트 명에 대한 확장 기능은 프록시와 같은 다른 HTTP 애플리케이션에 문제를 발생시킬 수 있다.
히스토리 확장
과거에 사용자가 방문했던 URL의 기록을 저장해 일부 입력시 과거에 입력했던 URL로 이동
프록시를 사용할 경우 URL 자동 확장 기능은 다르게 동작할 수 있다.
❓ 왜 프록시 사용시 주의해야할까
4. 안전하지 않은 문자
URL은 상대적으로 작고 일반적으로 안전한 알파벳 문자만 포함하도록 허락한다. 하지만 알파벳 이외의 문자도 포함하려는 시도가 있어 이런 경우를 위해 이스케이프라는 기능을 추가해 안전하지 않은 문자를 안전한 문자로 인코딩할 수 있도록 했다.
4.1 URL 문자 집합
컴퓨터 시스템의 기본 문자 집합은 영어 중심으로 설정되었고, US-ASCII 문자 집합을 사용해왔지만 이에 해당하지 않는 문자의 사용이 늘어나며(한국어와 같은..!) URL에 이스케이프 문자열을 쓸 수 있도록 설계되었다. 이스케이프 문자열은 특정 문자나 데이터를 인코딩할 수 있게 함으로써 이동성과 완성도를 높였다.
4.2 인코딩 체계
안전하지 않는 문자는 % 로 시작해 ASCII 코드로 표현되는 두 개의 16진수 숫자로 이루어진 이스케이프 문자로 변경된다.
4.3 문자 제한
몇몇 문자는 URL 내에서 컴포넌트를 구분하기 위해 미리 예약되어있기도 하고 제한되어있기도 하다.
https://stackoverflow.com/questions/695438/what-are-the-safe-characters-for-making-urls
4.4 좀 더 알아보기
입력받은 URL에서 어떤 문자를 인코딩해야 하는지 결정하는데는 브라우저와 같이 사용자로부터 최초로 URL을 입력받는 어플리케이션단에서 결정하는 것이 가장 적절하다.
❓ 모든 문자를 인코딩하면 되지 않을까?
→ 안전한 문자들을 인코딩하지 않는 애플리케이션도 있기 때무네 오동작을 일으킬 수 있다.
PRO-FE...!!!!!