HTTP 메시지

학습목표

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

1. 메시지의 흐름

HTTP 메시지는 HTTP 애플리케이션 간에 주고받은 데이터의 블록들이다. 이 데이터의 블록들은 텍스트 메타 정보로 시작하고 그 다음에 선택적으로 데이터가 올 수 있다. 이 메시지는 클라이언트, 서버, 프록시 사이를 흐른다. 인바운드, 업스트림, 다운스트림은 메시지의 방향을 의미한다.

1) 메시지는 원 서버 방향을 인바운드로 하여 송신한다.

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

HTTP 메시지는 모두 다운스트림으로 흐른다.

---

2. 메시지의 각 부분

   메시지는 요청이나 응답 중 하나를 포함한다. 메시지는 시작줄, 헤더 블록, 본문 이렇게 세 부분으로 이루어진다.

• 시작줄 : 어떤 메시지인지 서술한다.
• 헤더 블록 : 속성을 담는다.
• 본문 : 데이터를 담는다. 없을 수도 있다.

   시작줄과 헤더는 그냥 줄 단위로 분리된 아스키 문자열이다. 각 줄은 캐리지 리턴(ASCII 13)과 개행문자(ASCII 10)로 구성된 두 글자의 줄바꿈 문자열(CRLF)로 끝난다.
   HTTP 명세에 따른다면 줄바꿈 문자열은 CRLF이지만 견고한 애플리케이션이라면 그냥 개행 문자도 받아들일 수 있어야 한다. 오래되거나 잘못된 어플리케이션들 중에서는 캐리지 리턴과 개행 문자 모두를 항상 전송하지는 않는 것들도 있다.

1) 메시지 문법

• 요청 메시지의 형식
  

• 응답 메시지의 형식
  

2) 시작줄

   모든 HTTP 메시지는 시작줄로 시작한다.

😸요청줄

• 요청 메시지의 시작줄이다.
• 서버에서 어떤 동작이 일어나야 하는지 설명해주는 메서드와 요청 URL, HTTP 버전을 포함한다.

🐰응답줄

• 수행 결과에 대한 상태 정보와 결과 데이터를 클라이언트에게 돌려 준다.
• HTTP 버전, 상태 코드, 사유 구절이 들어 있다.

3) 헤더

• 일반, 요청, 응답, Entity, 확장 헤더로 분류된다.
• Entity 헤더 : 본문 크기와 콘텐츠, 혹은 리소스 그 자체를 서술
• 확장 헤더 : 명세에 정의되지 않은 헤더

---

3. 메서드

1) Safe Method

• GET과 HEAD는 안전하다고 할 수 있다.
• 두 메서드는 요청의 결과로 서버에 어떤 작용도 없기 때문이다.

2) GET

• 주로 서버에게 리소스를 달라고 요청하기 위해 쓰인다.
• HTTP/1.1은 서버가 이 메서드를 구현할 것을 요구한다.

3) HEAD

• 정확히 GET처럼 행동하지만, 서버는 응답으로 헤더만을 돌려준다.

🎅HEAD를 사용하면....

• 리소스를 가져오지 않고도 그에 대해 무엇인가를 알아낼 수 있다.
• 응답의 상태 코드를 통해, 개체가 존재하는지 확인할 수 있다.
• 헤더를 확인하여 리소스가 변경되었는지 검사할 수 있다.

• 반환되는 헤더가 GET으로 얻는 것과 정확히 일치함을 보장해야 한다.
• HTTP/1.1 준수를 위해서는 HEAD 메서드가 반드시 구현되어 있어야 한다.

4) PUT

• 서버에 문서를 쓴다.
• 서버가 요청의 본문을 가지고 요청 URL의 이름대로 새 문서를 만들거나, 교체한다.
• 많은 웹 서버가 PUT을 수행하기 전에 로그인을 요구할 것이다.

5) POST

• 서버에 입력 데이터를 전송하기 위해 설계되었다.
• HTML 폼을 지원하기 위해 흔히 사용된다.
• 채워진 폼에 담긴 데이터는 서버로 전쇵되며, 서버는 이를 모아서 필요로 하는 곳에 보낸다.

6) TRACE

• 클라이언트에게 자신의 요청이 서버에 도달했을 때 어떻게 보이게 되는지 알려준다.
• 목적지 서버에서 루프백(loopback) 진단을 시작한다. 요청 전송의 마지막 단계에 있는 서버는 자신이 받은 요청 메시지를 본문에 넣어 TRACE 응답을 되돌려준다.
• 진단을 위해 사용할 때는 괜찮지만, 메서드를 구별하는 메커니즘을 제공하지 않는다는 문제가 있다.

7) OPTIONS

• 웹 서버에게 여러 가지 종류의 지원 범위에 대해 물어본다. 즉, 서버에게 특정 리소스에 대해 어떤 메서드가 지원되는지 물어볼 수 있다.

8) DELETE

9) 확장 메서드

• 필요에 따라 확장해도 문제가 없도록 설계되어 있으므로, 새로 기능을 추가해도 과거에 구현된 소프트웨어들의 오동작을 유발하지 않는다.
• HTTP/1.1 명세에 정의되지 않은 메서드다.
• 어떤 확장 메서드를 정의한다면, 대부분의 HTTP 애플리케이션이 이해할 수 없을 것이다. 반대의 상황도 마찬가지이다.
• 이런 상황에서는 관용적으로 대처하는 것이 최고다.
• 프록시는 종단 간(end-to-end) 행위를 망가뜨리지 않을 수 있다면, 알려지지 않은 메서드가 담긴 메시지를 다운스트림 서버로 전달하려고 시도한다.
• 그렇지 않다면 프락시는 501 Not Implemented 상태 코드로 응답해야 한다.
• 확장 메서드를 다룰 때는 "엄격하게 보내고 관대하게 받아들여라"라는 오랜 규칙에 따르는 것이 가장 좋다.