3장. [HTTP - 웹의 기초] HTTP 메시지

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

❐ 1. 메시지의 흐름

---

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

HTTP 메시지의 인바운드 / 아웃바운드 개념

• HTTP는 트랜잭션의 방향을 설명하기 위해 인바운드, 아웃바운드 용어를 사용한다
• 메시지가 원 서버를 향해 이동하면 인바운드이다
• 모든 처리가 끝난 뒤 메시지가 사용자 에이전트로 돌아오면 아웃바운드이다
• 중간에 프락시가 여러 개 있더라도 방향의 기준은 항상 원 서버이다

요청과 응답의 방향성

• 요청 메시지는 클라이언트에서 서버로 이동하므로 인바운드
• 응답 메시지는 서버에서 클라이언트로 이동하므로 아웃바운드
• 요청과 응답은 서로 반대 방향으로 흐르지만 하나의 트랜잭션을 이룬다

1-2. 다운스트림으로 흐르는 메시지

HTTP 메시지의 업스트림 / 다운스트림 개념

• HTTP 메시지는 강물처럼 항상 다운스트림 방향으로 흐른다
• 메시지의 송신자는 수신자의 업스트림
• 메시지를 받는 쪽은 항상 다운스트림

❐ 2. 메시지의 각 부분

---

2-1. HTTP 메시지는 구조화된 데이터 블록이다

HTTP 메시지의 본질

• HTTP 메시지는 단순하지만 구조화된 데이터 블록
• 각 메시지는 요청 또는 응답 중 하나
• 메시지는 시작줄, 헤더 블록, 본문으로 구성된다
• 본문은 선택 사항이며, 없는 경우도 있다

텍스트 기반 프로토콜

• 시작줄과 헤더는 줄 단위로 구분된 ASCII 문자열
• 각 줄은 캐리지 리턴(CR)과 개행(LF)으로 끝난다
• 견고한 구현은 CRLF가 아닌 개행 문자만 와도 처리 가능해야 한다

---

2-2. 메시지 문법

요청 메시지와 응답 메시지

• 모든 HTTP 메시지는 요청 메시지 또는 응답 메시지
• 요청 메시지는 서버에게 동작을 요구
• 응답 메시지는 요청 처리 결과를 클라이언트에게 반환
• 두 메시지는 구조는 같고 시작줄 문법만 다르다

2-3. 시작줄

요청줄(Request Line)

• 서버에게 무엇을 할지를 설명
• 메서드, 요청 URL, HTTP 버전을 포함
• 모든 필드는 공백으로 구분된다
• HTTP/1.0 이전에는 버전 정보가 없었다

응답줄(Status Line)

• 요청 처리 결과를 설명
• HTTP 버전, 상태 코드, 사유 구절로 구성
• 모든 필드는 공백으로 구분된다
• HTTP/1.0 이전에는 응답줄이 없었다

2-4. 메서드

메서드의 역할

• 클라이언트가 서버에게 수행해 달라고 요청하는 동작
• 한 단어로 표현된다 (GET, POST 등)
• HTTP 명세는 공통 메서드 집합을 정의한다

주요 HTTP 메서드

• GET: 서버에서 문서를 가져온다
• HEAD: 문서에 대한 헤더만 가져온다
• POST: 서버가 처리해야 할 데이터를 전송
• PUT: 요청 메시지 본문을 저장
• DELETE: 서버에서 문서를 제거
• TRACE: 프락시 경로 추적
• OPTIONS: 서버가 지원하는 메서드 확인

메서드 확장성

• 모든 서버가 모든 메서드를 구현할 필요는 없다
• HTTP는 확장을 고려해 설계됨
• 서버별로 추가 메서드를 정의할 수 있다

2-5. 상태 코드

상태 코드의 의미

• 요청 처리 결과를 나타내는 세 자리 숫자
• 응답 메시지의 시작줄에 위치
• 첫 번째 숫자는 상태 코드의 분류를 나타낸다

상태 코드 분류

• 100–199: 정보
• 200–299: 성공
• 300–399: 리다이렉션
• 400–499: 클라이언트 에러
• 500–599: 서버 에러

상태 코드 처리 원칙

• 알 수 없는 상태 코드는 같은 범주의 일반 코드처럼 처리
• 숫자 코드는 기계 처리에 적합
• 사유 구절은 사람을 위한 설명일 뿐, 의미 판단 기준이 아니다

2-6. 사유 구절 (Reason Phrase)

사유 구절의 역할

• 상태 코드에 대한 사람이 읽기 쉬운 설명
• 상태 코드 이후에 위치
• 상태 코드와 1:1로 대응되지 않을 수 있다

사유 구절의 특징

• 애플리케이션 로직 판단 기준으로 사용하면 안 된다
• 동일한 상태 코드라도 사유 구절은 달라질 수 있다
• HTTP는 사유 구절에 대해 엄격한 규칙을 두지 않는다

2-7. 버전 번호

HTTP 버전의 의미

• 요청과 응답 메시지 양쪽에 포함된다
• 애플리케이션이 지원하는 HTTP 프로토콜 수준을 나타낸다
• 형식: HTTP/<메이저>.<마이너>

버전 비교 규칙

• 버전은 소수가 아니라 숫자 쌍
• 메이저와 마이너를 각각 비교해야 한다
• 예: HTTP/2.22 > HTTP/2.3

호환성 주의 사항

• 응답의 버전은 서버가 이해할 수 있는 수준을 의미
• 버전 불일치로 인한 혼란이 발생할 수 있다

2-8. 헤더

헤더의 역할

• 요청과 응답에 추가 정보를 제공
• 이름과 값의 쌍으로 구성
• 시작줄 다음에 0개 이상 존재 가능

헤더의 기본 문법

• 이름: 값
• 헤더 블록은 빈 줄(CRLF)로 끝난다
• 일부 HTTP 버전은 특정 헤더의 존재를 요구한다

---

2-9. 헤더 분류

헤더 분류

• 일반 헤더
  • 요청과 응답 모두에 사용 가능
• 요청 헤더
  • 요청에 대한 부가 정보 제공
• 응답 헤더
  • 응답에 대한 부가 정보 제공
• 엔터티 헤더
  • 본문 크기, 타입, 리소스 자체를 설명
• 확장 헤더
  • 명세에 정의되지 않은 사용자 정의 헤더

2-10. 헤더 줄 나누기

긴 헤더 처리

• 긴 헤더는 여러 줄로 나눌 수 있다
• 다음 줄은 반드시 공백 또는 탭으로 시작해야 한다
• 가독성을 높이기 위한 문법이다

2-11. 엔터티 본문

엔터티 본문의 개념

• HTTP 메시지의 화물(payload)
• 선택적인 데이터 블록
• 이미지, HTML, 비디오, 소프트웨어 등 다양한 데이터 가능

본문 존재 여부

• 모든 메시지가 엔터티 본문을 가지는 것은 아니다
• 본문이 없으면 헤더 뒤에 바로 CRLF로 종료된다

2-12. HTTP/0.9 메시지

HTTP/0.9의 특징

• HTTP의 초기 버전
• 요청은 메서드와 URL만 포함
• 응답은 엔터티 본문만 존재

HTTP/0.9의 한계

• 상태 코드, 헤더, 버전 정보 없음
• 다양한 상황을 표현할 수 없음
• 오늘날의 HTTP 기능 대부분을 지원하지 못함

HTTP/0.9의 존재 이유

• 여전히 일부 오래된 애플리케이션이 사용
• HTTP 발전 과정을 이해하기 위한 참고 대상

❐ 3. 메서드

---

3-1. HTTP 메서드 개요

메서드의 역할

• 클라이언트가 서버에게 무엇을 할지 요청하는 수단
• 모든 서버가 모든 메서드를 구현할 필요는 없다
• HTTP/1.1 호환 서버는 최소한 GET, HEAD를 구현해야 한다
• 메서드 사용은 서버 설정과 정책에 따라 제한될 수 있다

3-2. 안전한 메서드 (Safe Method)

안전한 메서드의 의미

• 서버의 상태를 변경하지 않는 메서드
• 대표적으로 GET, HEAD
• 서버에 부작용이 없어야 한다는 의도적 약속

주의할 점

• 안전한 메서드라도 실제 구현에 따라 서버 동작이 발생할 수 있다
• 안전한 메서드는 사용자에게 위험이 없음을 알리기 위한 개념

3-3. GET

GET 메서드의 특징

• 가장 널리 사용되는 메서드
• 서버로부터 리소스를 조회
• HTTP/1.1 서버는 반드시 GET을 지원해야 한다
• 요청 본문은 보통 사용하지 않는다

3-4. HEAD

HEAD 메서드의 특징

• GET과 동일하게 동작하지만 본문은 반환하지 않음
• 오직 헤더만 반환

사용 목적

• 리소스 존재 여부 확인
• 리소스 타입, 크기 확인
• 리소스 변경 여부 확인

구현 규칙

• HEAD 응답 헤더는 GET 응답 헤더와 완전히 동일해야 한다

3-5. PUT

PUT 메서드의 특징

• 서버에 리소스를 생성하거나 교체
• 요청 URL이 리소스의 위치를 직접 지정
• 본문에 저장할 데이터 포함

주의 사항

• 서버의 리소스를 변경하므로 보안 제약이 필요
• 많은 서버는 PUT 사용 전에 인증을 요구한다

3-6. POST

POST 메서드의 특징

• 서버에 데이터를 전송
• 서버는 데이터를 가공하거나 다른 시스템으로 전달할 수 있다.

PUT과의 차이

• PUT: 리소스를 URL에 직접 저장
• POST: 서버가 데이터 처리 방식을 결정

3-7. TRACE

TRACE 메서드의 목적

• 요청이 서버까지 어떻게 전달되는지 경로 추적
• 서버는 받은 요청을 그대로 응답 본문에 반환

특징

• 주로 진단 및 디버깅용
• 요청 본문을 가질 수 없다
• 보안상 비활성화되는 경우가 많다

3-8. OPTIONS

OPTIONS 메서드의 목적

• 서버 또는 특정 리소스가 지원하는 메서드 목록 확인
• 실제 리소스를 접근하지 않고 기능만 조회

응답 특징

• Allow 헤더에 지원 메서드 목록 포함

3-9. DELETE

DELETE 메서드의 특징

• 지정한 URL의 리소스 삭제 요청
• 삭제가 반드시 수행된다는 보장은 없다.

특징

• 서버는 요청을 무시할 수도 있다.
• 응답 메시지는 성공 여부만 전달할 수 있다.

3-10. 확장 메서드

확장 메서드의 개념

• HTTP 명세에 정의되지 않은 메서드
• 서버가 자체적으로 정의하여 사용

특징

• 프락시는 모르는 메서드를 관대하게 전달해야 한다
  • 프락시는 중간자일 뿐, 프로토콜 확장을 막는 게이트키퍼가 되면 안 됨
  • 그래서 모르는 메서드는 ‘최대한 있는 그대로’ 전달
  • 단, 전달 불가/정책 차단 같은 예외 상황에서는 실패 응답 가능
• 처리할 수 없으면 501 Not Implemented 반환
• WebDAV 메서드(LOCK, COPY, MOVE 등)가 대표적 예