[HTTP] 5. 메세지 (Message)

• 메시지가 어떻게 흘러가는가
• HTTP 메시지의 세 부분 (시작줄, 헤더, 개체 본문)
• 요청과 응답 메시지의 차이
• 요청 메시지가 지원하는 여러 기능(method)
• 응답 메시지가 반환하는 상태 코드(status code)
• 여러 HTTP 헤더들은 무슨 일을 하는가

별도 정리 및 의문점

entity란 무엇인가? https://linuxism.ustd.ip.or.kr/45

안전한 메서드의 목적 (61p)이 정확히 무엇인지 이해가 가지 않습니다.

PUT : 요청의 본문을 가지고, 요청 URL의 이름대로 새 문서를 만들거나 교체하도록 하는 것이다. → 이 말의 의미가, PUT 메서드의 REST한 의미에 더 부합하는 것인지?

3.1 메세지의 흐름

HTTP 메시지는 HTTP 애플리케이션 간에 주고 받는 데이터 블록 으로, 메시지의 내용과 의미를 설명하는 텍스트 메타 정보로 시작하여 선택적으로 데이터가 온다.

메시지는 클라이언트, 서버, 프락시 사이를 흐르며, '인바운드', '아웃바인드', '업스트림', '다운스트림'은 메시지의 방향을 의미하는 용어이다.

3.1.1 메시지는 원 서버 방향을 인바운드하여 송신된다.

메시지가 클라이언트에서 서버로 올라가는 것을 인바운드, 반대로 사용자 에이전트, 즉 클라이언트 쪽으로 내려오는 것을 아웃바인드라고 한다.

3.1.2 다운스트림으로 흐르는 메시지

HTTP는 요청이냐 응답이냐에 관계없이 모두 다운스트림으로 흐른다. 메시지 발송자는 수신자의 업스트림 이라고 하고, 수신자는 다운스트림이라고 한다. 따라서 어느 한 쪽의 업스트림이면서 다운스트림일 수도 있다.

3.2 메시지의 각 부분

HTTP 메시지는 단순히 구조화된 블록이다. 각 메시지는 클라이언트로부터 요청, 서버로부터의 응답 중 하나를 포함한다. 메시지는 시작줄, 헤더 블록, 본문, 이렇게 세 부분으로 되어 있다.

시작줄은 이것이 어떠한 메시지인지에 대한 메타 정보를 담고 있고, 헤더 블록은 속성을, 본문은 데이터를 담고 있다. 본문은 없을 수도 있다.

시작줄과 헤더의 구분은 사실, 그저 캐리지 리턴과 개행 문자로 구성되어 있다. 다만 오래된 HTTP 어플리케이션이나 잘못 만든 HTTP 어플리케이션은 개행문자만으로 되어 있어 있는 경우도 있으니 그냥 개행문자만도 처리할 수 있어야 한다.

HTTP/1.0 200 OK            // 시작줄
Content-type: text/plain   // 헤더
Content-Length: 19         // 헤더
Hi! I'm a message!         // 본문

3.2.1 메시지 문법

모든 HTTP는 요청 또는 응답이다. 요청은 서버로 어떤 동작을 요구하고, 응답은 그 결과를 반환한다. 요청과 응답은 기본 구조가 같다.

// 요청
GET /specials/saw-blade.gif HTTP/1.0  // 메서드, 요청 URL, 버전
HOST: www.joes-hardware.com           // 헤더
                                      // 헤더와 본문 사이에는 공백 라인(CRLF)가 있다.
                                      // 본문

// 응답
HTTP/1.0 200 OK                       // 버전, 상태코드, 사유구절
Content-Type: image/gif               // 헤더
Content-Length: 8572
                                      // 헤더와 본문 사이에는 공백 라인(CRLF)가 있다.
                                      // 본문

요청은 위와 같이 메서드, 요청 URL, 버전과, 헤더, 엔터티 본문으로 구성되고, 응답은 버전과 상태코드, 사유구절, 헤더, 엔터티 본문으로 구성된다. 보다시피 첫번째 줄만이 다르다.

메서드는 클라이언트가 서버에 요구하는 것으로, GET, HEAD, POST 등의 한 단어로만 구성이 되어 있다. 요청 URL은 리소스를 지칭하는 완전한 URL, 혹은 경로 구성 요소를 의미한다.

버전은 HTTP/<메이저><마이너>의 형식을 따르며, 메이저와 마이너는 모두 정수이다. 상태코드는 요청 중에 일어난 것을 설명하는 세 자리 숫자이다. 첫번째 자릿수는 상태의 일반적인 분류로, 성공 또는 에러 등을 나타낸다.

사유구절은 숫자로 된 상태코드를 설명해주는 짧은 문구다, 사실 사유구절은 읽히기 위해 존재하는 텍스트일 분, 아무런 의미를 가지지 못한다. 만약 상태코드가 동등하게 200이면 하나는 OK, 하나는 NOT OK여도 둘은 성공한 것으로 본다.

헤더 는 이름, 콜론, 선태적인 공백, 값, CRLF가 순서대로 나타나는 것으로, 없을 수도 있다. 다만 HTTP/1.1 같은 몇몇 버전에서는 반드시 포함되는 헤더 종류가 있다.

마지막으로 엔터티 본문은 임의의 데이터 블록을 포함한다. 메시지는 없을 수도 있고, 이런 경우 헤더와 본문 사이의 공백 라인이었던 CRLF로 끝나게 된다. 즉, 본문이 없어도 CRLF로 끝난다.

다만 많은 구현체가 이것을 잊곤 하니, 클라이언트와 서버는 CRLF가 없는 경우도 고려하여 만들어져야 한다, 각각의 요소에 대한 자세한 설명은 해당 챕터에서 이어서.

3.2.2 시작줄

모든 HTTP 메시지는 시작줄로 시작한다. 요청은 무엇을 해야 하는지, 응답은 무엇이 일어났는지를 담고 있다. 위에도 언급했지만, 아래처럼 풀어서 이야기해보자.

요청줄은 어떤 동작을 해야 하는지, 그것이 어디에 있는지를 지칭하는 요청 URL, 클라이언트가 어떤 HTTP 버전으로 말하고 있는지를 서버에 알려주는 HTTP 버전을 포함한다. 각각의 필드는 공백문자로 구분된다.

응답줄은 수행결과에 대한 상태 정보, 결과 데이터를 클라이언트에게 준다. 시작줄 혹은 응답줄에는, 응답 메시지에 쓰인 HTTP의 버전, 숫자로 된 상태 코드, 수행 상태를 설명하는 사유 구절이 있다. HTTP/1.0 이전에는 없었다.

요청줄은 메서드로 시작하는데, HTTP 명세는 공통 요청 메서드의 집합을 정의한다, 예를 들면,

• GET : 서버에서 어떤 문서를 가져온다.
• HEAD : 서버에서 어떤 문서의 '헤더'만 가져온다.
• POST : 서버에서 처리해야 할 데이터를 보낸다. 당연히 메시지의 본문을 가진다.
• PUT : 서버에서 요청 메시지의 본문을 저장한다. 당연히 메시지의 본문을 가진다.
• TRACE : 메시지가 프락시를 거쳐 서버에 도달하는 과정을 추적한다.
• DELETE : 서버에서 문서를 제거한다.

이 메서드들은 쓸 수도 안쓸 수도 있고, HTTP 자체가 추가적인 메서드를 구현할 수 있어서, 새로운 메서드를 정의할 수도 있다. 이런 경우에는 확장 메서드라고 부른다.

상태 코드 는 무엇이 일어났는지를 말한다. 사유구절이 사람에게 이해하기 편하다면, 컴퓨터가 처리하기에는 숫자가 더 좋다. 상태 코드를 확장할 경우에는 일반적인 이해 범주로 담아야 한다. (ex. 성공한 경우면 2로 시작해야 한다.)

사유구절은 상태코드와 일대일로 대응한다, 다만 어떠한 규칙도 없으며, 아무런 영향도 가지지 못한다, 그저 상태 코드를 보다 쉽게 이해하기 위한 메시지일 뿐이다.

버전 번호는 HTTP/x.y 형식으로 기술되며 자신의 프로토콜 버전을 상대에게 알려준다. 이는 서로 불가능한 기능을 사용하지 않으려는 배려이다. 오해하지 말아야 하는 것은 각자 자신이 이해할 수 있는 버전 한계를 말한다는 점이다.

이것을 상대가 준 메시지의 버전이라고 생각해선 안 된다.

3.2.3 헤더

HTTP 헤더 명세는 여러 헤더 필드를 정의한다. 애플리케이션은 자신만의 헤더를 만들 수도 있다. 분류는 아래와 같다.

일반 헤더 는 요청과 응답 양쪽에 모두 나타낼 수 있다.

요청 헤더 요청에 대한 부가 정보를 나타낸다.

응답 헤더 응답에 대한 부가 정보를 나타낸다.

Entity 헤더 는 본문 크기와 콘텐츠, 혹은 리소스 그 자체를 서술한다. Entity에 대한 의미는 별도 정리하겠다.

확장 헤더 는 명세에 정의되지 않은 새로운 헤더를 의미한다.

헤더는 키와 값으로 이루어진 한 쌍으로 이루어지며 한 줄로 표현되지만, 만일 너무 길다면 개행을 하되 하나의 스페이스 이상의 들여쓰기를 통해 앞 헤더의 연장선임을 표현해주어야 한다.

3.2.4 엔티티 본문

HTTP 메시지의 세 번째 부분은 선택적인 엔티티 본문이다. 이는 HTTP 메시지의 화물, 또는 옮기고자 하는 것 그 자체이다.

3.2.5 버전 0.9 메시지

HTTP/0.9는 HTTP 프로토콜의 초기 버전이다. 요청은 그저 메서드와 URL만을 가지고 있고 응답은 본문만을 가진다. 매우 단순한 구조로 이루어져 있어서 많은 상황에 대응할 수는 없지만, 여전히 구식 클라이언트, 서버 등이 있으니 주의.