HTTP 메시지

3. HTTP 메시지

3.1 메시지의 흐름

HTTP메시지는 HTTP 애플리케이션 간에 주고받은 데이터의 블록들

이 데이터의 블록들은 메시지의 내용과 의미를 설명하는 텍스트 메타 정보로 시작하고 그 다음에 선택적으로 데이터가 올 수 있다.

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

HTTP는 인바운드와 아웃바운드라는 용어를 트랜잭션 방향을 표현하기 위해 사용

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

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

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

HTTP 메시지는 강물과 같이 흐른다(다운스트림)

메시지의 발솔자는 수신자의 업스트림

3.2 메시지의 각 부분

HTTP 메시지는 단순한, 데이터의 구조화된 블록

메시지는 시작줄, 헤더 블록, 본문 이렇게 세 부분으ㄹ ㅗ이루어짐

시작줄은 이것이 어떤 메시지인지 서술(ex. HTTP/1.0 200 OK)

헤더 블록은 속성(ex. Content-type: text/plain)

본문은 데이터(ex. hi)

시작줄과 헤더는 그냥 줄 단위로 분리된 아스키 문자열(CRLF로 구분)

본문은 단순히 선택적인 데이터 덩어리

3.2.1 메시지 문법

모든 HTTP 메시지는 요청 메시지나 응답 메시지

요청 메시지는 웹 서버에 어떤 동작을 요구

응답 메시지는 요청의 결과를 클라이언트에게 되돌려 줌

요청 메시지의 형식

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

<엔티티 본문>

응답 메시지의 형식

<버전> <상태 코드> <사유 규절>
<헤더>

<엔티티 본문>

메서드

클라이언트 측에서 서버가 리소스에 대해 수정해주길 바라는 동작 (ex. GET, HEAD, POST)

요청 URL

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

버전

HTTTP 버젼

상태 코드

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

사유 구절(reason-phrase)

숫자로 된 상태 코드의 의미를 사람이 이해할 수 있게 설명해주는 짧은 문구

헤더들

엔티티 본문

임의의 데이터 블록

3.2.2 시작줄

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

요청줄

요청 메시지의 시작줄(요청줄)에는 서버에서 어떤 동작이 일어나야 하는지 설명해주는 메서드와 그 동작에 대한 대상을 지칭하는 요청 URL이 들어있다.

또한 어떤 HTTP 버전으로 말하고 있는지 서버에게 알려주는 HTTP 버전도 포함

이 모든 필드는 공백으로 구분

응답줄

응답 메시지는 수행 결과에 대한 상태 정보와 결과 데이터를 클라이언트에게 돌려줌

HTTP 버전, 상태 코드, 사유 구절

공백으로 구분

메서드

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

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

상태코드

메서드가 서버에게 무엇을 해야 하는지 말해주는 것처럼, 상태 코드는 클라이언트에게 무엇일 일어났는지 말해줌

상태 코드들은 세 자리 숫자로 된 그들의 코드값을 기준으로 묶인다

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

사유 구절

사유 구절은 상태 코드와 일대일 대응

상태 코드의 사람이 이해하기 쉬운 버전

버전 번호

자신이 따르는 프로토콜의 버전을 상대방에게 말해주기 위한 수단

3.2.3 헤더

헤더 분류

• 일반 헤더: 요청과 응답 양쪽에 모두 나타날 수 있음
• 요청 헤더: 요청에 대한 부가 정보를 제공
• 응답 헤더: 응답에 대한 부가 정보를 제공
• Entity 헤더: 본문 크기와 컨텐츠, 혹은 리소스 그 자체를 기술
• 확장 헤더: 명세에 정의되지 않은 새로운 헤더

헤더를 여러 줄로 나누기

긴 헤더 줄은 그들을 여러 줄로 쪼개서 더 읽기 좋게 만들 수 있는데, 추가 줄 앞에는 최소 하나의 스페이스 혹은 탭 문자가 와야 한다.

3.2.4 엔티티 본문

HTTP 메시지의 화물

3.2.5 버전 0.9 메시지

요청은 그저 메서드와 요청 URL 뿐

응답은 오직 엔터티

3.3 메서드

모든 서버가 모든 메서드를 구현하지 않음

3.3.1 안전한 메서드(Safe Method)

GET과 HEAD는 안전함(서버에 어떠한 작용도 없음)

HTTP 요청의 결과로 인해 서버에서 일어나는 일은 아무것도 없다는 의미

3.3.2 GET

주로 서버에게 리소스를 달라고 요청하기 위해 쓰임

3.3.3 HEAD

GET 처럼 행동하지만, 서버는 응답으로 헤더만을 돌려줌

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

3.3.4 PUT

서버에 문서를 쓴다

서버가 요청의 본문을 가지고 요청 URL의 이름대로 새 문서를 만들거나, 이미 URL이 존재한다면 본문을 사용하여 고체

3.3.5 POST

서버에 입력 데이터를 전송하기 위해 설계

3.3.6 TRACE

자신의 요청이 서버에 도달했을 때 어떻게 보이게 되는지 알려줌

요청 전송의 마지막 단계에 있는 서버는 자신이 받은 요청 메시지를 본문에 넣어 TRACE 응답으로 되돌려줌

주로 진단을 위해 사용

TRACE 응답의 엔티티 본문에는 서버가 받은 요청이 그대로 들어있다.

3.3.7 OPTIONS

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

3.3.8 DELETE

리소스 삭제

3.3.9 확장 메서드

새로 기능을 추가해도 과거에 구현된 소프트웨어들의 오동작을 유발하지 않음

확장 메서드를 다룰 때는 “엄격하게 보내고 관대하게 받아들여라”

3.4 상태 코드

상태 코드는 클라이언트에게 그들의 트랜잭션을 이해할 수 있는 쉬운 방법을 제공

3.4.1 100-199: 정보성 상태 코드

HTTP/1.1에서 도입

100 Continue는 HTTP 클라이언트 애플리케이션이 서버에 엔티티 본문을 전송하기 전에 그 엔터티 본문을 서버가 받아들일 것인지 확인하려고 할 때, 그 확인 작업을 최적화하기 위한 의도로 도입된 것

클라이언트와 100 Continue

최적화를 위한 것

서버와 100 Continue

100 Continue 혹은 에러 코드로 응답해야 합

프락시와 100 Continue

HTTP/1.1을 받지 못한다면 다음으로 전달해야 한다

프락시가 다음 홉 서버들에 대한 상태 몇 가지와 그들이 지원하는 HTTP 버전을 기억해둔다면, 100-Continue 응답을 기대한 요청을 더 잘 다룰 수 있게 되므로 프락시에게 이득이 된다.

3.4.2 200-299 성공 상태 코드

서버는 대응하는 성공을 의미하는 상태 코드의 배열을 갖고 있으며, 각각 다른 종류의 요청에 대응

3.4.3 300-399 리다이렉션 코드

클라이언트가 관심있어 하는 리소스에 대해 다른 위치를 사용하라고 말해주거나 그 리소스의 내용 대신 다른 대안 응답을 제공

리다이렉션 상태 코드 중 몇몇은 리소스에 대한 애플리케이션의 로컬 복사본이 원래 서버와 비교했을 때 유효한지 확인하기 위해 사용

3.4.4 400-499: 클라이언트 에러 코드

잘못 구성된 요청 메시지 같은 것 또는 존재하지 않는 URL에 대한 요청

3.4.5 500-599: 서버 에러 상태 코드

클라이언트가 올바른 요청을 보냈음에도 서버 자체에서 에러가 발생하는 경우

3.5 헤더

• 일반 헤더(General Headers)

  클라이언트아와 서버 양쪽 모두 사용

  다양한 목적으로 사용(ex. Date)

• 요청 헤더(Request Headers)

  요청 메시지를 위한 헤더

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

• 응답 헤더(Response Headers)

  응답 메시지는 클라이언트에게 정보를 제공하기 위한 자신만의 헤더를 갖고 있다(ex. 서버 버전)

• 엔티티 헤더(Entity Headers)

  엔티티 본문에 대한 헤더(ex. Content-Type: text/html)

• 확장 헤더(Extension Headers)

  아직 승인된 HTTP 명세에는 추가되지 않은 비표준 헤더

3.5.1 일반 헤더

메시지에 대한 아주 기본적인 정보 제공

일반 캐시 헤더

HTTP/1.0은 HTTP 애플리케이션에게 매번 원 서버로부터 객체를 가져오는 대신 로컬 복사본으로 캐시할 수 있도록 해주는 최초의 헤더 도입

헤더	설명
Cache-control	메시지와 함께 캐시 지시자를 전달하기 위해 사용
Pragma	메시지와 함께 지시자를 전달하는 또 다른 방법. 캐시에 국한되지 않음 (deprecated)

3.5.2 요청 헤더

요청 메시지에서만 의미를 갖는 헤더

요청이 최초 발생한 곳에서 누가 혹은 무엇이 그 요청을 보냈는지에 대한 정보나 클라이언트의 선호나 능력에 대한 정보를 줌

Accept 관련 헤더

서버에게 자신의 선호와 능력을 알려줄 수 있다.

조건부 요청 헤더

클라이언트는 서버에게 요청에 응답하기 전에 먼저 조건이 참인지 확인하게 하는 제약을 포함시킬 수 있다.

요청 보안 헤더

자체적으로 요청을 위한 간단한 인증요구/응답 체계를 갖고 있음 -> 안전하게 만들고자 함

프락시 요청 헤더

프락시 기능을 돕기 위한 헤더

3.5.3 응답 헤더

클라이언트에게 부가 정보를 제공

누가 응답을 보내고 있는지 혹은 응답자의 능력은 어떻게 되는지 알려주며, 더 나아가 응답에 대한 특별한 설명도 제공 가능

협상 헤더

HTTP/1.1은 서버와 클라이언트가 어떤 표현을 택할 것인지 협상 가능(ex. 프랑스어, 독일어..)

응답 보안 헤더

기본적인 인증요구 헤더

3.5.4 엔티티 헤더

엔티티와 그것의 내용물에 대한, 개체의 타입부터 시작해서 주어진 리소스에 대해 요청할 수 있는 유효한 메서드들까지, 광범위한 정보를 제공

콘텐츠 헤더

엔티티의 콘텐츠에 대한 구체적인 정보 제공

종류, 크기, 기타 콘텐츠를 처리할 때 유용하게 활용할 수 있는 것들 (ex. Content-Type)

엔티티 캐싱 헤더

엔티티 캐싱에 대한 정보 제공

캐시된 사보인 아직 유효한지 또는 캐시된 리스소가 더 이상 유효하지 않게 되는 시점을 더 잘 추정하기 위한 단서

참조

1. HTTP 완벽 가이드