HTTP가 인터넷의 배달원이라면 HTTP 메시지는 무언가를 담아 보내는 소포와 같다.
메시지의 흐름.
HTTP 메시지는 HTTP 어플리케이션 간에 주고 받은 데이터의 블록들이다.
HTTP 메시지는 메시지의 내용과 의미를 설명하는 텍스트 Metadata로 시작하고 그 다음 선택적으로 데이터가 올 수 있다.
HTTP 메시지는 클라이언트 서버 프록시 사이를 흐른다.
인바운드,아웃바운드,업스트림,다운스트림은 메시지의 뱡향을 의미하는 용어다.
메시지는 원 서버 방향을 인바운드로 하여 송신된다.
HTTP는 인바운드와 아웃바운드라는 용어를 트랜잭션 방향을 표현하기 위해 사용한다.
Transection
HTTP 요청 명령과 응답 결과.
HTTP 메시지라는 정형화 된 데이터를 주고 받는 것을 의미한다.
서버로 메시지를 보낼 때에는 인바운드,
서버에서 클라이언트로 이동하는 것은 아웃바운드이다.
다운스트림으로 흐르는 메시지
HTTP 메시지는 강물과 같이 흐른다.
요청 메시지나 응답 메시지냐에 관계 없이 모든 메시지는 다운 스트림으로 흐르며 메시지의 발송자는 수신자의 업스트림이 된다.
메시지의 각 부분
HTTP는 단순한 데이터의 구조화 된 블록이다.
구조화란 시작줄,헤더블록,본문 이렇게 세 부분으로 나누어진 것을 말한다.
시작줄은 어떤 메시지인지 서술하며, 헤더 블록은 속성을, 본문은 데이터를 담고 있다.
본문은 옵셔널이다.
시작줄과 헤더는 줄 단위로 분리된 아스키 문자열이다.
각 줄은 캐리지 리턴(ASCII 13)과 개행 문자(ASKII 10)로 구성된 두 글자의 줄바꿈 문자열로 끝난다.
이 줄바꿈 문자열은 'CRLF'라고 쓴다.
HTTP 명세에 따른다면 줄바꿈 문자열은 CRLF이지만 견고한 어플리케이션이라면 그냥 개행 문자도 받아들일 수 있어야 한다.
CRLF (Carriage Return Line Feed)
\n\r
Carriage Return : 맨 앞쪽으로 이동하라는 뜻
Line Feed : 새로운 줄에서 시작.
CRLF : 새로운 줄의 제일 앞쪽에서 시작.
메시지 문법
모든 HTTP 메시지는 요청 메시지나 응답 메시지로 분류된다.
요청 메시지는 웹 서버에 어떤 동작을 요구한다.
응답 메시지는 요청의 결과를 클라이언트에게 돌려준다.
요청과 응답 모두 기본적으로 구조가 같지만 디테일한 형식은 조금 다르다
요청 메시지
<method><request URL><version>
Get: /specials/something.gif HTTP/1.0
<header>
<body>응답 메시지
<version><state code><reason-phrase>
HTTP/1.0 200 OK
<header>
<body>첫째 줄 (HTTP message의 구성 요소)
method
클라이언트 측에서 서버가 리소스에 대해 수행해주기 바라는 동작이며 한 단어로 작성된다.
TRACE는 프록시를 거쳐 서버에 도달하는 과정을 추적할 수 있고
OPTIONS는 서버가 어떤 메서드를 수행할 수 있는지 확인한다.
메서드는 쉽게 확장할 수 있게 설계되었기 때문에 다른 서버는 그들만의 확장 메서드가 포함될 수 있다.
state code
각 코드의 첫번째 자릿수는 상태의 일반적인 분류를 나타낸다.
300번대는 re-direction으로 리소스가 옮겨졌음을 나타낸다.
400번대는 클라이언트의 잘못된 요청
500번대는 서버에서 무언가 실패했음을 의미한다.
reason-phrase
숫자로 된 상태 코드의 의미를 사람이 이해할 수 있게 설명해주는 짧은 문구.
프로토콜이 진화하면서 더 많은 상태코드가 HTTP 명세에 공식적으로 정의되고 있으며 코드와 사유구절을 읽고 어디가 잘못되었는지 찾아낼 수 있어야 한다.
헤더
HTTP 헤더 명세는 여러 헤더 필드를 정의한다.
어플리케이션은 또한 자유롭게 자신만의 헤더를 만들어낼 수 있다.
헤더의 분류
- 일반 헤더 : 요청과 응답 양쪽에 모두 나타날 수 있다
- 요청 헤더 : 요청에 대한 부가 정보 제공
- 응답 헤더 : 응답에 대한 부가 정보 제공
- Entity 헤더 : 본문 크기와 콘텐츠 혹은 리소스 그 자체를 서술
- 확장 헤더 : 명세에 정의되지 않은 새로운 헤더
각 HTTP 헤더는 간단한 문법을 가지며
이름 - 쉼표 - 공백 - 필드 값 - CRLF가 순서대로 온다.
Date: tue, 3 Oct 1997 02:16:03 GMT : 서버가 응답을 만들어 낸 시각
Content-length:15040 : 15040바이트의 데이터를 포함한 본문
Content-type: image/gif : entity 본문은 GIF 이미지.엔터티 본문 (body)
HTTP 메세지의 세번째 구성 요소.
HTTP 메시지는 이미지,비디오,문서,트렌잭션,이메일 등 여러 데이터를 실어 나른다.
구형 HTTP 버전은 메시지와 요청 URL만 갖고 있을 뿐이며
응답은 오직 본문으로만 되어 있다.
메서드의 종류
GET : 가장 흔히 쓰는 메서드로 서버에 리소스를 요청하기 위해 쓰인다.
HEAD : GET처럼 헹동하지만 서버는 응답으로 헤더만을 보내준다.
- 본문이 반환되지 않으므로 리소스를 가져오지 않고 정보를 알아낼 수 있다
- 응답의 상태 코드를 통해 개체의 존재유무를 확인한다.
- 헤더를 통해 리소스가 변경되었는지 검사할 수 있다.
PUT : 서버에 리소스를 갱신/생성하고 변경된 값을 디스크에 저장하게 한다.
PUT이 생성한다는 것은 서버에 이미 존재하는 리소스(ex: file)에 데이터를 입력한다는 것을 의미한다.
서버가 요청의 본문을 가지고 새 문서를 만들거나 이미 URL이 존재한다면 본문을 사용해서 교체할 수 있다.
PUT은 콘텐츠를 변경할 수 있기 때문에 PUT을 수행하기 전에 사용자의 인증이 필요할 것이다.
POST : POST 메서드는 서버에 입력 데이터를 전송하기 위해 설계되었다.
실제로 HTML 폼을 지원하기 위해 흔히 사용된다.
채워진 폼에 담긴 데이터는 서버로 전송되며, 서버는 이를 모아서 필요로 하는 곳에 보낸다.
TRACE : 클라이언트가 요청을 보낼 때 방화벽,프락시,게이트웨이 등을 통과할 수 있다. 이들에게는 원래의 HTTP 요청을 수정할 수 있는 기회가 있다.
TRACE 메서드는 클라이언트에게 자신의 요청이 서버에 도달했을 때 어떻게 보이게 되는지 알려준다.
TRACE 요청은 목적지 서버에서 루프백 진단을 시작한다.
요청 전송의 마지막 단계에 있는 서버는 자신이 받은 요청 메시지를 본문에 넣어 TRACE 응답을 되돌려 주는데, 클라이언트와 목적지 서버 사이에 있는 모든 HTTP 어플리케이션의 요청/응답 연쇄를 따라가면서 메시지가 어떻게 변경되었는지 확인하며 진단/검사할 수 있다.
OPTIONS : OPTIONS 메서드는 웹 서버에게 여러 가지 종류의 지원 범위에 대해 물어본다. 서버에게 특정 리소스에 대해 어떤 메서드가 지원되는지 물어볼 수 있다. 리소스에 대해 실제 접근하지 않고 어떻게 접근하는 것이 최선인지 확인할 수 있는 수단인 것이다.
DELETE : 삭제. 하지만 클라이언트는 삭제가 수행되는 것을 보장하지 못한다. HTTP 명세에서 서버가 클라이언트에게 알리지 않고 요청을 무시하는 것을 허용하기 때문이다.
