[HTTP 완벽가이드 3장] HTTP 메세지

---

1부.HTTP : 웹의 기초

---

3장.HTTP 메세지

---

3.1 메시지의 흐름

• HTTP 메시지는 HTTP 애플리케이션 간에 주고 받은 데이터의 블록들
• 데이터의 블록들은 메시지의 내용과 의미를 설명하는 텍스트 메타 정보로 시작
• 메시지는 클라이언트, 서버, 프락시 사이를 흐름
• 인바운드, 아웃바운드, 업스트림, 다운스트림은 메시지의 방향을 의미

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

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

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

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

• 모든 메시지는 다운스트림으로 흐름

• 즉, 메시지의 발송자는 수신자의 업스트림이 됨

3.2 메시지의 각 부분

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

• 클라이언트 요청이나 서버 응답 중 하나를 포함

• 시작줄, 헤더, 본문으로 구성

• 시작줄 & 헤더: 줄 단위로 분리된 아스키(ASCII) 문자열. 각 줄은 캐리지 리턴과 개행 문자로 구성된 두 글자의 줄바꿈으로 끝나고,
  이 줄바꿈 문자열을 - CRLF라고 칭함.

• 본문은 선택적인 데이터 덩어리. 텍스트나 이진 데이터를 포함할 수도 있고, 그냥 비어 있을 수도 있음.

  1) 메시지 문법

  • 요청과 응답은 구조가 동일하나 시작줄에서만 문법이 다름

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

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

    [요청 메세지 형식]  
    [메시지] [요청 URL] [HTTP 버전]  
    [헤더]  

    [본문]  

    ex)  
    GET /specials/saw-blade.gif HTTP/1.0  
    Host: www.joes-hardware.com

    [응답 메세지 형식]  
    [HTTP 버전] [상태 코드] [사유 구절]    
    [헤더]  

    [본문]    

    ex)  
    HTTP/1.0 200 OK  
    Content-Type: image/gif  
    Content-Length: 8572 

(1) 메서드  

클라이언트 측에서 서버가 리소스에 대해 수행해주길 바라는 동작을 의미
GET, POST, HEAD와 같이 한 단어로 되어 있음

(2) 요청 URL  

요청 대상이 되는 리소스를 지칭

(3) 버전  

HTTP 버전
형식: HTTP/<메이저>.<마이너>

(4) 상태 코드  

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

(5) 사유 구절(reason-phase)  

숫자로 된 상태 코드의 의미를 이해할 수 있게 도와주는 짧은 문구

(6) 헤더들

이름, 콜론(:), 선택적인 공백, 값, CRLF가 순서대로 나타나는 0개 이상의 헤더들
HTTP/1.1과 같은 몇몇 버전의 HTTP는 요청이나 응답에 어떤 특정 헤더가 포함되어야만 유효한 것으로 간주

(7) 엔터티 본문

임의의 데이터 블록을 포함
필수 요소가 아니므로 간혹 메시지는 CRLF로 끝남

2) 시작줄

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

• 요청 메시지의 시작줄은 무엇을 해야 하는지, 응답 메시지의 시작줄은 무슨 일이 일어났는지 말해줌

  
  

  (1) 요청줄

  서버에서 어떤 동작이 일어나야 하는지 설명해주는 메서드
  그 동작에 대한 대상을 지칭하는 요청 URL
  클라이언트가 어떤 HTTP 버전으로 말하고 있는지 서버에게 알려주는 HTTP 버전으로 구성되어 있음

(2) 응답줄

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

(3) 메서드

HTTP 명세는 공통 요청 메서드의 집합을 정의하고 있음
요청 메시지에 따라 본문이 있을 수도 있고 없을 수도 있음
확장 메서드: HTTP 명세를 확장하여 추가로 구현된 메서드

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

(4) 상태 코드와 사유 구절

상태 코드는 각 응답 메시지의 시작줄에 담겨 반환
숫자로 된 코드 + 문자열로 된 사유 구절: 서로 일대일 대응

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

(5) 버전 번호

HTTP 애플리케이션이 자신이 따르는 프로토콜의 버전을 상대방에게 말해주기 위한 수단
어떤 애플리케이션이 지원하는 가장 높은 HTTP 버전을 가리킴
HTTP/1.1의 의미는 HTTP/1.1의 메시지가 아니라, HTTP/1.1까지 이해할 수 있음을 의미
HTTP 버전을 비교할 때는 ‘.’을 기준으로 분리하여 진행해야 함
HTTP/2.22는 HTTP/2.3보다 큼. ‘.’을 기준으로 2는 동일하지만, 22와 3 중 22가 더 크기 때문임.

3) 헤더

• 요청과 응답 메시지에 추가 정보를 더함

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

헤더 ex)

Date: Tue, 3 Oct 2019 03:20:49 KST    
: 서버가 응답을 만들어 낸 시각

Content-length: 4942    
: 4942 바이트의 데이터를 포함한 엔터티 본문

Content-type: image/gif    
: 엔터티 본문은 GIF 이미지

Accept: image/gif, image/jpeg, text/html    
: 클라이언트는 GIF, JPEG, HTML을 받아들일 수 있다

4) 엔터티 본문

• HTTP 메시지의 세번째 부분은 선택적인 엔터티 본문
• 이미지, 비디오, HTML 문서, 소프트웨어 애플리케이션, 신용카드 트랜잭션, 전자우편 등 여러 종류의 디지털 데이터를 수송할 수 있음

5) 버전 0.9 메시지의 제약

• HTTP 버전 0.9는 초기 버전이며 굉장히 단순한 프로토콜로 되어 있음
• HTTP/0.9 메시지도 요청과 응답으로 이루어져 있으나
• 요청은 메서드와 요청 URL을 가지고 있을 뿐이며
• 응답은 오직 엔터티로만 되어 있음
• 버전 정보, 상태 코드, 사유 구절, 헤더가 포함되어 있지 않음을 유의

3.3 메서드

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

• 그렇다고 하더라도 메서드는 대부분 제한적으로 사용

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

  • HTTP는 안전한 메서드라고 불리는 메서드의 집합을 정의
  • GET, HEAD는 안전하다고 정의할 수 있는데, HTTP 요청의 결과로 서버에 어떤 작용도 없기 때문이다.
  • 안전한 메서드의 목적은, 서버에 영향을 줄 수 있는 안전하지 않은 메서드가 사용될 때 사용자에게 알려줄
    수 있는 HTTP 애플리케이션을 만들도록 하는 것에 있음

  2) GET

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

  3) HEAD

  • 정확히 GET처럼 행동하지만, 서버는 응답으로 헤더만을 돌려줌. 엔터티 본문은 반환되지 않음
  • 리소스를 가져오지 않고도 타입 등을 알아낼 수 있음
  • 응답의 상태 코드를 통해 개체가 존재하는지 확인 가능
  • 헤더를 확인하여 리소스가 변경됐는지 검사할 수 있음
  • HTTP/1.1 준수를 위해서는 HEAD 메서드가 반드시 구현되어 있어야 함

  4) PUT

  • 서버가 요청의 본문을 가지고 요청 URL의 이름대로 새 문서를 만들거나, 이미 URL이 존재한다면 본문을 사용해서 교체
  • 콘텐츠를 변경할 수 있게 해줌; 사용자에게 로그인 요구

  5) POST

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

  6) TRACE

  • 클라이언트에게 자신의 요청이 서버에 도달했을 때 어떻게 보이게 되는지 알려줌
  • 목적지 서버에서 ‘루프백(loopback)’ 진단을 함; 서버는 요청 메시지를 본문에 넣어 TRACE 응답을 되돌려줌
  • 주로 진단할 때나 프락시/타 애플리케이션 요청에 어떤 영향을 미치는지 확인하고자 할 때 사용
  • 서버의 엔터티 본문을 리턴받지 않고 서버가 받은 요청이 그대로 엔터티 본문에 들어 있음

  7) OPTIONS

  • 서버에게 여러 가지 종류의 지원 범위에 대해 물어봄; 특정 리소스에 어떤 메서드가 지원되는지

  8) DELETE

  • 서버에게 요청 URL로 지정한 리소스를 삭제할 것을 요청
  • 단, 삭제 수행 보장은 못함; 서버가 클라이언트에게 알리지 않고 요청 무시하는 것을 허용하기 때문

  9) 확장 메서드

  • HTTP/1.1 명세에 정의되지 않은 메서드로, 필요에 따라 확장해도 문제가 없도록 설계되어 있기
    때문에 과거 구현한 소프트웨어의 오동작을 유발하지는 않음
    ‘Be conservative in what you send, be liberal in what you accept.’ (엄격하게 보내고 관대하게 받아들여라)
  • 프락시는 종단 간(end-to-end) 행위를 망가뜨리지 않을 수 있다면 알려지지 않은 메서드가 담긴 메시지를
    다운스트림 서버로 전달하려고 시도, 그렇지 않다면 501 Not Implemented 상태 코드로 응답해야 함

3.4 상태 코드(생략)

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

3.5 헤더

1) 일반 헤더 (General Headers)

• 메시지에 대한 아주 기본적인 정보를 제공
• Connection, Date, MIME-Version, Trailer chunked transfer, Transfer-Encoding, Upgrade, Via 등을 포함

2) 요청 헤더 (Request Headers)

• 요청 메시지에서만 의미를 갖는 헤더
• Client-IP, From, Host, Referer, User-Agent 등을 포함
• 서버에게 자신의 선호와 능력을 알려주는 Accept 관련 헤더; Accept, Accept-Charset, Accept-Encoding, Accept-Language 등을 포함
• 트랜잭션을 보다 안전하게 만들기 위한 요청 보안 헤더; Authorization, Cookie 등을 포함
• 프락시 기능을 도울 수 있는 프락시 요청 헤더; Max-Forwards, Proxy-Authorization, Proxy-Connection 등을 포함

3) 응답 헤더 (Response Headers)

• 클라이언트가 응답을 더 잘 다루고 추후 더 나은 요청을 할 수 있게 도와줌
• Age, Public, Server, Warning 등을 포함
• 요청 보안 헤더와 비슷한 응답 보안 헤더; Set-Cookie 등을 포함

4) 엔터티 헤더 (Entity Headers)

• 엔터티와 그것의 내용물에 대한 - 개체의 타입, 메서드 등 - 광범위한 정보 제공
• Allow, Location 등을 포함
• 엔터티의 콘텐츠에 대한 구체적인 정보를 제공하는 콘텐츠 헤더; Content-Base, Content-Encoding,
  Content-Lauguage, Content-Length, Content-Type 등을 포함