HTTP 완벽 가이드 3장
3장 HTTP 메시지
1. 메시지의 흐름
HTTP 메시지란?
HTTP 애플리케이션 간에 주고받는 데이터 블록들
HTTP 메시지의 흐름
클라이언트 <-> 프록시 <-> 서버 사이를 흐른다.
메시지 방향과 관련한 용어로는 인바운드
, 아웃바운드
, 업스트림
, 다운스트림
가 있다.
인바운드와 아웃바운드
인바운드
와 아웃바운드
라는 용어는 트랜잭션 방향을 표현하기 위해 사용된다.
클라이언트에서 원 서버로 향하는 것은 인바운드
라 하며, 원 서버에서 클라이언트로 향하는 것은 아웃바운드
라고 한다.
(기준점을 원서버로 잡으면 된다.)
다운스트림
모든 메시지는 폭포처럼 다운스트림
으로 흐른다.
2. 메시지 요소
메시지는 클라이언트의 요청 혹은 서버의 응답 중 하나를 포함한다.
메시지는 시작줄
, 헤더 블록
, 본문
으로 구성된다.
시작줄
: 어떤 메시지인지 서술한다.헤더 블록
: 속성을 표시한다.본문
: 데이터를 담고 있으며, 없을 수도 있다.
위의 그림을 보면, 헤더를 통해 본문에 대한 정보를 얻을 수 있다.content-type
을 통해 text/plain
형식임을 알 수 있다.
1) 메시지 문법
클라이언트 요청
- 시작줄 :
메서드
,요청 URL
,HTTP 버전
- 헤더
- 엔터티 본문
서버 응답
- 시작줄 :
버전
,상태 코드
,사유 구절
- 헤더
- 엔터티 본문
메서드
클라이언트에서 서버가 수행해주길 바라는 동작GET
, POST
, PUT
등 의 메서드가 존재한다.
1 |
|
위의 시작줄은 서버에게 GET
메서드를 전달하였다.
다음은 메서드에 대한 설명이다.
메서드 | 설명 | 메시지 본문 존재 여부 |
---|---|---|
GET | 서버에서 어떤 문서를 가져온다. | 없음 |
HEAD | 서버에서 어떤 문서에 대해 헤더만 가져온다. | 없음 |
POST | 서버가 처리해야할 데이터를 보낸다. | 있음 |
PUT | 서버에 요청 메시지의 본문을 저장한다. | 있음 |
TRACE | 메시지가 프록시를 거쳐 서버에 도달하는 과정을 추적 | 없음 |
OPTIONS | 서버가 어떤 메서드를 수행할 수 있는지 확인 | 없음 |
DELETE | 서버에서 문서를 제거한다. | 없음 |
이 외의도 사용자가 확장 메서드를 통해 메서드를 추가할 수 있다.
요청 URL
요청 대상의 리소스를 지징하는 전한 URL 혹은 URL의 경로 구성요소이다.
URL의 경로 구성요소여도 클라이언트와 서버가 통신중이고 리소스를 가리키는 절대경로라면 일반적으로 문제되지 않는다.
버전
메시지에서 사용중인 HTTP의 버전으로 다음과 같이 표현한다.
1 |
|
버전 번호는 현재 통신에서 지원하는 가장 높은 HTTP 버전을 가리키며, 통신한 버전보다 낮은 HTTP 버전으로 통신한 경우 높은 버전의 새로운 기능을 사용할 수 없다.
상태 코드
클라이언트와 서버 간의 통신에서 다양한 상황이 발생하며, 클라이언트에게 무엇이 일어났는지 3자리 숫자로 전달하는 값이다.
첫번째 자리는 성공/실패 등의 일반적 분류를 표현한다.
1 |
|
위의 내용의 상태코드는 200이다.
첫번째 코드값 기준으로 묶이며, 그 기준은 다음과 같다.
전체 범위 | 정의된 범위 | 분류 |
---|---|---|
100-199 | 100-101 | 정보 |
200-299 | 200-206 | 성공 |
300-399 | 300-305 | 리다이렉션 |
400-499 | 400-415 | 클라이언트 에러 |
500-599 | 500-505 | 서버 에러 |
위의 코드값 외에도 정의가 가능하며, 해당 코드 대역으로 가정하고 다뤄야한다.
예를 들어, 상태코드가 515 라면 5XX 메시지들과 마찬가지로 서버 에러를 의미하는 것으로 간주해야한다.
다음은 자주 사용되는 상태 코드이다.
상태 코드 | 사유 구절 | 의미 |
---|---|---|
200 | OK | 성공, 요청한 데이터는 응답 본문에 있다. |
401 | Unathorized | 사용자 이름과 비밀번호를 입력해야한다. |
404 | Not Found | 서버는 요청한 URL에 해당하는 리소스를 찾지 못했다. |
사유 구절
상태 코드의 의미를 사람이 알 수 있도록 설명하는 문구
상태코드와 일대일로 대응된다.
헤더
이름과 클론, 공백, 값, CRLF(줄바꿈) 로 표현한다.
엔터티 본문
임의의 데이터 블록을 포함한다.
모든 메시지가 엔터티 본문을 갖지 않으므로, CRLF 로 끝나는 경우가 있다.
3. 헤더
헤더 필드는 요청과 응답 메시지에 추가 정보를 더한다.
기본적으로 이름/값으로 된 쌍의 목록이다.
헤더 분류
애플리케이션은 자유롭게 자신만의 헤더를 만들어 낼 수 있다.
- 일반 헤더 : 요청과 응답 양쪽 모두 나타날 수 있다.
- 요청 헤더 : 요청에 대한 부가 정보 제공 (예: 클라이언트가 받고자 하는 데이터 타입)
- 응답 헤더 : 응답에 대한 부가 정보 제공 (예: 클라이언트가 어떤 종류의 서버가 대화화고 있는지에 대한 정보)
- 엔티티 헤더 : 본문 크기와 콘텐츠, 혹은 리소스 그 자체를 기술
- 확장 헤더 : 명세에 정의되지 않은 새로운 헤더
헤더의 예 | 설명 |
---|---|
Date: Tue, 3 Oct 1997 02:16:03 GMT | 서버가 응답을 만들어 낸 시각 |
Content-length: 15040 | 15,040 바이트의 데이터를 포함한 엔티티 본문 |
Content-type: image/gif | 엔티티 본문은 GIF 이미지이다. |
Accept: image/gif, iamge/jpeg, text/html | 클라이언트는 GIF, JPEG 이미지와 HTML을 받을수 있다. |
헤더는 여러줄로 쪼개서 표현할 수 있으며, 추가줄 앞에 최소 하나의 스페이스 혹은 탭 문자가 와야한다.
4. 엔티티 본문
HTTP 메시지의 세번째 부분으로 선택적인 엔티티 본문이다.
HTTP 메시지의 화물이라 할 수 있으며, 이미지, 비디오, HTML 문서, 소프트웨어 애플리케이션, 신용카드 트랜잭션, 전자우편 등의 다양한 디지털 데이터를 실어 나를 수 있다.
5. 버전 0.9 메시지
HTTP 프로토콜의 초기 버전으로, 단순한 프로토콜로 되어 있다.
동일하게 요청과 응답으로 이루어져있으나, 요청은 메서드와 요청 URL 만 존재하며, 응답은 오로지 엔티티 본문만 존재한다.
이로 인해 다양한 상황에 대응할 수 없다.
3. 메서드
1. 안전한 메서드
GET
과 HEAD
메서드는 안전한 메서드인데, 두 메서드의 요청 결과로는 서버에 어떠한 동작도 이뤄지지 않기 때문이다.
예를 들어 구매
버튼을 누른다하더라도, GET
메서드로는 신용카드의 정보가 담긴 POST
요청이 전달되지 않기 때문에 신용카드 대금이 청구되지 않는다.
물론, 안전한 메서드라 서버 개발자가 어떻게 개발하느냐에 따라 다른 결과가 일어날 수 있음은 알아야한다.
2. GET
가장 흔히 쓰이는 메서드로 서버에게 리소스를 달라고 요청하는 메서드이다.
3. HEAD
GET 과 동일하게 동작하지만, 서버는 헤더만을 돌려주며, 엔티티 본문은 반환되지 않는다.
리소스를 실제로 가져올 필요 없이 헤더만 이용해서 리소스 타입이나, 응답의 상태 코드 등을 통해 개체가 존재하는지 확인가능하며, 리소스가 변경되었는지도 검사가 가능하다.
4. PUT
서버가 요청의 본문을 가지고 요청 URL의 이름대로 새 문서를 만들거나 이미 존재할 경우 본문을 사용해서 교체할 때 사용된다.
직접적으로 콘텐츠를 변경할 수 있기 때문에, 서버가 사용자의 인증정보를 요구하도록 한다.
5. POST
서버의 입력 데이터를 전송하기 위해 사용된다. 채워진 데이터는 서버로 전송된다.
6. TRACE
클라이언트에게 자신의 요청이 서버에 도달했을 때 어떻게 보이게 되는지 알려준다.
요청 전송의 지막 단계에 있는 서버는 자신이 받은 요청 메시지를 본문에 넣어 TRACE 응답을 되돌려준다.
클라이언트는 자신과 서버 사이에 있는 모든 HTTP 애플리케이션의 요청/응답을 따라가면서 자신이 보낸 메시지가 정상적으로 전달되었는지, 수정되었다면 어떻게 변경되었는지 확인할 수 있다.
주로 진단을 위해 사용되지만, 중간 애플리케이션이 여러 종류의 요청 메서드를 사용할 경우 문제가 발생할 수 있다.
예를 들어 프록시는 POST 요청을 바로 통과시키지만, GET 은 웹 캐시와 같은 다른 애플리케이션으로 전송하기 때문이다.
또한, TRACE 요청은 어떠한 엔티티 분문도 보낼 수 없다.
7. OPTIONS
웹 서버에게 메서드 지원 종류를 물어보며, 자신의 리소스에 대해 지원하는 메서드 목록을 반환한다.
8. DELETE
서버에게 요청 URL 로 지정한 리소스를 삭제할 것을 요청한다.
하지만, 삭제가 수행된다고 보장할 수는 없다. (서버가 클라이언트에게 알리지 않고 요청을 무시하는 것을 허용하기 때문이다.)
9. 확장 메서드
필요에 따라 확장할 수 있으며, 새로운 기능을 추가해도 과거에 구현된 소프트웨어가 오작동을 하진 않는다.
메서드 | 설명 |
---|---|
LOCK | 사용자가 리소스를 잠글수 있게해준다. 예를 들어 컨플루언스 |
COPY | 서버에 있는 리소스를 복사한다. |
MOVE | 서버에 있는 리소스를 옮긴다. |