HTTP 완벽 가이드 _ 3장

3장. HTTP 메시지

HTTP가 인터넷의 배달원이라면, HTTP 메시지는 무언가를 담아 보내는 소포와 유사하다!

 

1. 메시지의 흐름

우선 HTTP 메시지란? -> HTTP 애플리케이션 간에 주고받은 데이터의 블록들.

메시지는 클라이언트, 서버, 프락시 사이를 흐름.

 

메시지 흐름의 특징

1-1) 메시지는 원 서버 방향을 인바운드를 하여 송신

인바운드 : 메시지가 서버 방향으로 향하는 것.

아웃바운드 : 모든 처리가 끝난 뒤 메시지가 사용자 에이전트로 돌아오는 것.

 

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

요청/응답 메시지와 관계없이 모든 메시지는 다운스트림으로 흐름.

(메시지의 발송자는 수신자의 업스트림!)

 

2. 메시지의 각 부분

메시지 : 시작줄(어떤 메시지인지) + 헤더 블록(속성) + 본문(데이터/없을 수도 있음)

 

시작줄과 헤더는 -> 줄 단위로 분리된 아스키 문자열(이때 줄 바꿈 문자열이 CRLF)

본문은 -> 단순한 선택적 데이터 덩어리

 

2-1) 메시지 문법

모든 HTTP 메시지 = 요청 or 응답! -> 기본적으로 둘의 구조는 같음.

 

메시지 형식↓

요청 메시지 형식

<메서드> <요청 URL> <버전>

<헤더>

 

<본문>

 

응답 메시지 형식

<버전> <상태 코드> <사유 구절>

<헤더>

 

<엔터티 본문>

 

용어 설명 ↓

- 메서드

: 클라이언트 측에서 서버가 리소스에 대해 수행해주길 바라는 동작.

 

- 요청 URL

: 요청 대상인 리소스를 지칭하는 완전한 URL 혹은 URL의 경로 구성요소.

 

- 버전

: 해당 메시지에서 사용 중인 HTTP의 버전.

 

- 상태 코드

: 요청 중에 무엇이 일어났는지 설명하는 세 자리의 숫자.

 

- 사유 구절

: 상태 코드의 의미를 사람이 이해할 수 있게 설명해주는 짧은 문구.

(오직 사람에게 읽히기 위해 존재)

 

- 헤더

: 이름, : , 선택적 공백, 값, CRLF가 순서대로 나타남.

 

- 엔터티 본문

: 임의의 데이터 블록을 포함. 모든 메시지가 이를 갖지는 않음(이 때 메시지는 그냥 CRLF로 끝남).

 

2-2) 시작줄

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

요청 메시지 시작줄 -> 무엇을 해야 하는지 / 응답 메시지 시작줄 -> 무슨 일이 일어났는지

 

- 요청줄

: 요청 메시지의 시작줄.

-> 서버에서 어떤 동작이 일어나야 하는지 설명해주는 메서드와, 동작에 대한 대상을 지칭하는 요청 URL로 이루어짐.

 

- 응답줄

: 응답 메시지에 쓰인 HTTP 버전, 상태 코드, 사유 구절로 이루어짐.

 

- 메서드

: 요청의 시작줄은 메서드로 시작 -> 서버에게 무엇을 해야 하는지 말해줌.

메서드	설명	메시지 본문 유무
GET	서버에서 어떤 문서를 가져옴	없음
HEAD	서버에서 어떤 문서에 대한 헤더만 가져옴	없음
POST	서버가 처리해야 할 데이터를 보냄	있음
PUT	서버에 요청 메시지의 본문을 저장	있음
TRACE	메시지가 프락시를 거쳐 서버에 도달하는 과정을 추적	없음
OPTIONS	서버가 어떤 메서드를 수행할 수 있는지 확인	없음
DELETE	서버에서 문서를 제거	없음

- 상태 코드

: 클라이언트에게 무엇이 일어났는지 말해줌.

전체 범위	정의된 범위	분류
100 - 199	100 - 101	정보
200 - 299	200 - 206	성공
300 - 399	300 - 305	리다이렉션
400 - 499	400 - 415	클라이언트 에서
500 - 599	500 - 505	서버 에러

 

- 사유 구절

: 상태 코드와 일대일로 대응. 사람이 이해하기 쉬운 상태 코드.

 

2-3) 헤더

시작줄 다음에는 0개, 1개, 혹은 여러 개의 HTTP 헤더가 옴.

-> 요청과 응답 메시지에 추가 정보를 더함(기본적으로 이름/값 쌍의 목록 형태)

이름, 쉼표, 공백, 필드 값, CRLF 순으로 구성.

 

2-4) 엔터티 본문

HTTP 메시지의 세 번째 부분인 엔터티 본문 -> HTTP 메시지가 실어 나르는 데이터.

 

3. 메서드

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

HTTP 요청의 결과로 서버에 어떠한 작용도 없는 메서드 -> GET , HEAD

 

3-2) GET

가장 흔히 쓰이는 메서드! 주로 서버에게 리소스를 달라고 요청하기 위해 쓰임.

 

3-3) HEAD

GET처럼 행동. 서버는 응답으로 해당 데이터의 헤더만을 돌려줌(즉 본문은 절대 반환 x)

-> 리소스 가져오지 않고도 관련 정보(타입 등) 알 수 있음.

-> 응답 상태 코드를 통해 개체가 존재하는지 확인 가능

-> 리소스의 변경 유무 검사 가능.

 

3-4) PUT

서버에 문서를 작성하는 메서드.

-> 서버가 요청의 본문으로 요청 URL 이름의 새 문서를 만들거나, 이미 URL이 존재한다면 본문 이용해 교체.

 

3-5) POST

서버에 입력 데이터를 전송하는 메서드. 흔히 HTML form을 지원하기 위해 사용.

 

* POST는 서버에 데이터를 보내기 위해, PUT은 서버에 있는 리소스에 데이터를 입력하기 위해 사용

 

3-6) TRACE

주로 진단을 위해 사용.

-> 요청이 의도한 요청/응답을 거쳐가는지 검사.

 

3-7) OPTIOMS

웹 서버에게 여러 가지 종류의 지원 범위에 대해 물어봄.

(특정 리소스에 대해 어떤 메서드가 지원되는지)

 

3-8) DELETE

서버에게 요청 URL로 지정한 리소스를 삭제할 것을 요청.

 

* 클라이언트는 삭제 수행되었다고 보장 x

-> HTTP는 서버가 클라이언트에게 알리지 않고 요청 무시하는 걸 허용하기 때문

 

3-9) 확장 메서드

HTTP는 필요에 따라 확장해도 문제가 없도록 설계됨 -> 새로 기능 추가해도 오동작 유발 x

 

LOCK , COPY, MOVE 등 확장 메서드 허용.

 

4. 상태 코드

4-1) 100 - 109 : 정보성 상태 코드

4-2) 200 - 299 : 성공 상태 코드

4-3) 300 - 399 : 리다이렉션 상태 코드

클라이언트가 요청한 리소스에 대해, 다른 위치를 사용하라거나 리소스의 내용 대신 다른 대안 응답을 제공.

(ex 리소스가 옮겨졌다면 리다이렉션 상태 코드와 Location 헤더를 보내 알아서 새 위치로 이동하게끔)

4-4) 400 - 499 : 클라이언트 에러 상태 코드

클라이언트가 서버가 다룰 수 없는 무언가를 보냈을 때!

(클라이언트가 알 수 없는 리소스에 대해 요청할 때)

상태 코드	사유 구절	의미
400	Bad Request	클라이언트가 잘못된 요청 보냄
403	Forbidden	요청이 서버에 의해 거부됨(서버가 거절 이유를 숨기고 싶을 때)
404	Not Found	서버가 요청한 URL을 찾을 수 없을 때

4-5) 500 - 599 : 서버 에러 상태 코드

클라이언트가 올바른 요청을 보냈지만, 서버 자체에서 에러가 발생했을 때!

상태 코드	사유 구절	의미
500	Internal Server Error	서버가 요청을 처리할 수 없게 만드는 에러를 만났을 때
501	Not Implemented	클라이언트가 서버의 능력을 넘은 요청(ex 서버가 지원하지 않는 메서드 사용) 했을 때
502	Bad Gateway	프락시나 게이트웨이처럼 행동하는 서버가 그 요청 응답 연쇄에 있는 다음 링크로부터 가짜 응답에 맞닥뜨렸을 때(ex 자신의 부모 게이트웨이에 접속하는 게 불가능할 때)
503	Service Unavailable	현재는 서버가 요청을 처리해 줄 수 없지만, 나중에는 가능함을 의미하고자 할 때

 

5. 헤더

헤더와 메서드는 클라이언트와 서버가 무엇을 하는지 결정하기 위해 함께 사용됨.

 

5-1) 일반 헤더

클라이언트와 서버 둘 다 사용.

클라이언트, 서버, 기타 다른 애플리케이션들을 위해 다양한 목적으로 사용됨.

(ex Date: Tue, 3 Oct 1974 02:16:00 GMT -> 메시지 생성 일시를 지칭하는 Date 헤더) 

 

5-2) 요청 헤더

요청 메시지를 위한 헤더.

서버에게 클라이언트가 받고자 하는 데이터의 타입이 무엇인지와 같은 부가 정보 제공.

(ex Accept: */* -> 서버에게 클라이언트가 받아들일 미디어 타입을 지칭하는 Accept 헤더)

 

5-3) 엔터티 헤더

엔터티 본문에 대한 헤더.

(ex Content-Type: text/html -> 데이터의 타입을 알려주는 Content-Type 헤더)

 

5-4) 확장 헤더

애플리케이션 개발자들에 의해 만들어졌지만 아직 승인된 HTTP 명세에는 추가되지 않은 비표준 헤더.