메시지의 흐름
HTTP 메시지는 HTTP 애플리케이션 간에 주고받은 데이터의 블록들입니다.
메시지의 방향은 4가지가 있습니다.
- 인바운드
- 아웃바운드
- 업스트림
- 다운스트림
메시지가 원 서버로 향하는 것은 인바운드로 이동하는 것이고, 모든 처리가 끝난 뒤에 메시지가 사용자 에이전트로 돌아오는 것은 아웃바운드로 이동하는 것입니다.
요청, 응답 메시지냐에 관계없이 모든 메시지는 다운스트림으로 흐르고, 메시지의 발송자는 수신자의 업스트림입니다.
메시지의 각 부분
메시지의 형식은 다음과 같슷ㅂ니다.
요청 메시지
<메서드> <요청 URL> <버전>
<헤더>
<엔터티 본문>응답 메시지
<버전> <상태 코드> <사유 구절>
<헤더>
<엔터티 본문>- 메서드: 클라이언트 측에서 서버가 리소스에 대해 수행해주길 바라는 동작
- 요청 URL: 요청 대상이 되는 리소스를 지칭하는 완전한 URL 혹은 URL의 경로 구성요소
- 버전: 어떤 애플리케이션이 지원하는 가장 높은 HTTP 버전
- 상태 코드: 요청 중에 무엇이 일어났는지 설명하는 세 자리의 숫자
- 사유 구절(reason-phrase): 상태 코드의 의미를 사람이 이해할 수 있게 설명해주는 짧은 문구
- 헤더들: 클라이언트와 서버가 요청 또는 응답으로 부가적인 정보 전송
- 엔터티 본문: 임의의 데이터 블록을 포함
여기서 많이 쓰이는 HTTP 메서드는 다음과 같습니다.
| 메서드 | 설명 | 메시지 본문이 있는가? |
|---|---|---|
| GET | 서버에서 어떤 문서를 가져온다. | 없음 |
| HEAD | 서버에서 어떤 문서에 대해 헤더만 가져온다. | 없음 |
| POST | 서버가 처리해야 할 데이터를 보낸다. | 있음 |
| PUT | 서버에 요청 메시지의 본문을 저장한다. | 있음 |
| TRACE | 메시지가 프락시를 거쳐 서버에 도달하는 과정을 추적한다. | 없음 |
| OPTIONS | 서버가 어떤 메서드를 수행할 수 있는지 확인한다. | 없음 |
| DELETE | 서버에서 문서를 제거한다. | 없음 |
상태 코드
앞서 HTTP 상태 코드는 크게 다섯 가지로 나뉘는 것을 확인했습니다.
거기서 추가적으로 알아두면 좋겟다고 생각드는 부분을 정리하겠습니다.
100-199: 정보성 상태 코드
- 100 continue: 요청의 시작 부분 일부가 받아들여졌으며, 클라이언트는 나머지를 계속 이어서 보내야 함을 의미합니다. 이것을 보낸 후, 서버는 반드시 요청을 받아 응답해야 한다.
이 상태 코드에 대해서 좀 정리를 해두겠습니다.
클라이언트와 100 Continue
클라이언트 애플리케이션은 100-continue를 서버가 다루거나 사용할 수 없는 큰 엔터티를 서버에게 보내지 않으려는 목적으로만 사용해야 한다.
100-continue는 여러 측면에서 최적화를 위한 것임을 명심해야 합니다. 왜냐하면 이것은 클라이언트가 엔터티를 보낼 것이라고 생각하게 만들어 서버를 혼란에 빠뜨릴 수 있기 때문입니다.
서버와 100 Continue
서버는 절대로 100-continue 응답을 받을 것을 의도하지 않은 클라이언트에게 100 Continue 상태 코드를 보내서는 안됩니다.
프락시와 100 Continue
프록시의 경우 홉(next-hop) 서버로 네트워크에서 출발지와 목적지 사이에 위치한 경로의 한 부분입니다.
그렇기에 HTTP 버전에 따라 작동 방식이 나뉩니다.
- HTTP/1.1 & 어떤 버전인지 모르는 경우: Expect 헤더를 포함시켜서 요청 전달
- HTTP/1.1보다 이전 버전: 417 Expectation Failed 에러로 응답
- HTTP/1.0 & 이전 버전: 100 Continue 응답을 클라이언트에게 전달 X
300-399: 리다이렉션 상태 코드
리소스에 대한 내용 대신 리다이렉션 상태 코드와 (선택적으로)Location 헤더를 보내어 알아서 새 위치로 이동할 수 있게 해줍니다.
일반적으로, HEAD가 아닌 요청에 대해 리다이렉션 상태 코드를 포함한 응답을 할 때, 리다이렉트될 URL에 대한 링크와 설명을 포함시키는 것은 '좋은 습관'이다.
헤더
헤더와 메서드는 클라이언트와 서버가 무엇을하는지 결정하기 위해 함께 사용됩니다.
헤더는 크게 다섯 가지로 분류됩니다.
- 일반 헤더(General Headers): 아주 기본적인 정보 제공
- 요청 헤더(Request Headers): 요청 메시지를 위한 헤더
- 응답 헤더(Response Headers): 클라이언트에게 부가 정보를 제공하기 위한 헤더
- 엔터티 헤더(Entity Headers): 엔터티 본문에 대한 헤더
- 확장 헤더(Extension Headers): 애플리케이션 개발자들에 의해 만들어졌지만 아직 승인된 HTTP 명세에는 추가되지 않은 비표준 헤더
- 요청 헤더
요청 헤더에는 Accept 관련 헤더가 존재합니다.
클라이언트는 Accept 관련 헤더들을 이용해 서버에게 자신이 선호와 능력을 알려줄 수 있습니다.
클라이언트는 그들이 원하는 것을 얻을 수 있으며, 서버는 클라이언트가 사용할 수도 없는 것을 전송하는 데 시간과 대역폭을 낭비하지 않을 수 있습니다.
이 외에도 조건부 요청 헤더, 요청 보안 헤더, 프락시 요청 헤더가 존재합니다.
- 응답 헤더
응답 헤더에는 협상 헤더와 응답 보안 헤더가 존재합니다.
엔터티 헤더는 내용물에 대한, 개체의 타입부터 시작해서 주어진 리소스에 대해 요청할 수 있는 유효한 메서드들까지, 광범위한 정보를 제공합니다.
콘텐츠 헤더와 엔터티 캐싱 헤더가 존재합니다.
콘텐츠 헤더는 엔터티의 컨텐츠에 대한 구체적인 정보를 제공하고, 엔터티 캐싱 헤더는 엔터티 캐싱에 대한 정보를 제공합니다. (일반 캐싱 헤더는 언제 어떻게 캐시가 되어야 하는지에 대한 지시자를 제공합니다.)
Reference
