[HTTP] HTTP 메시지

3.1 메시지의 흐름

• HTTP 애플리케이션 간에 주고받은 데이터의 블록들을 나타내는 HTTP 메시지는, 클라이언트, 서버, 프락시 사이를 흐른다.
• 메시지의 방향에 따라 '인바운드', '아웃바운드', '업스트림', '다운스트림'으로 용어가 나뉜다.

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

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

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

• 모든 HTTP 메시지는 다운스트림으로 흐른다.
  

3.2 메시지의 각 부분

• HTTP 메시지는 단순한, 데이터의 구조화된 블록이다.
• 각 메시지는 클라이언트로부터의 요청이나 서버로부터의 응답 중 하나를 포함한다.
• 시작줄, 헤더 블록, 본문 부분으로 이루어진다.
  • 시작줄은 이것이 어떤 메시지인지 서술한다.
  • 헤더 블록은 메시지의 속성을 서술한다.
  • 본문은 데이터를 담고 있다. 본문 자체가 아예 없을 수도 있다.
    

3.2.1 메시지 문법

• 모든 HTTP 메시지는 요청 메시지나 응답 메시지로 분류된다.
  • 요청 메시지는 웹 서버에 어떤 동작을 요구한다.
    • 요청 메시지의 형식
      <메서드> <요청 URL> <버전>
      <헤더>
      ㅤ
      <엔터티 본문>
      ㅤ
  • 응답 메시지는 요청의 결과를 클라이언트에게 돌려준다.
    • 응답 메시지의 형식
      <버전> <상태 코드> <사유 구절>
      <헤더>
      ㅤ
      <엔터티 본문>
      ㅤ
• 각 부분에 대한 설명
  • 메서드: 클라이언트 측에서 서버가 리소스에 대해 수행해주길 바라는 동작(GET, POST 등)
  • 요청 URL: 요청 대상이 되는 리소스를 지칭하는 완전한 URL 혹은 URL의 경로 구성요소
  • 버전: 이 메시지에서 사용 중인 HTTP의 버전
  • 상태 코드: 요청 중에 무엇이 일어났는지 설명하는 세 자리의 숫자
  • 사유 구절: 숫자로 된 상태 코드의 의미를 사람이 이해할 수 있게 설명해주는 짧은 문구
  • 헤더들: 이름, 콜론(;), 선택적인 공백, 값, CRLF가 순서대로 나타나는 0개 이상의 헤더들
  • 엔터티 본문: 임의의 데이터 블록을 포함한다.

3.2.2 시작줄

• 모든 HTTP 메시지는 시작줄로 시작한다.

요청줄

• 요청 메시지는 서버에게 리소스에 대해 무언가를 해달라고 부탁한다.
• 모든 필드는 공백으로 구분된다.

응답줄

• 수행 결과에 대한 상태 정보와 결과 데이터를 클라이언트에게 돌려준다.
• 모든 필드는 공백으로 구분된다.

메서드

• 요청의 시작줄은 메서드로 시작하며, 서버에게 무엇을 해야 하는지 말해준다.
  • GET: 서버에서 어떤 문서를 가져온다
  • HEAD: 서버에서 어떤 문서에 대해 헤더만 가져온다
  • POST: 서버가 처리해야 할 데이터를 보낸다
  • PUT: 서버에 요청 메시지의 본문을 저장한다
  • TRACE: 메시지가 프락시를 거쳐 서버에 도달하는 과정을 추적한다
  • OPTIONS: 서버가 어떤 메서드를 수행할 수 있는지 확인한다
  • DELETE: 서버에서 문서를 제거한다

상태코드

• 클라이언트에게 무엇이 일어났는지 말해준다.
• 상태 코드는 각 응답 메시지의 시작줄의 담겨 반환된다.
• 숫자로 된 코드와 문자열로 되어 있어서 사람이 이해하기 쉬운 메시지 두 형태 모두로 반환된다.
  • 100-199: 정보
  • 200-299: 성공
  • 300-399: 리다이렉션
  • 400-499: 클라이언트 에러
  • 500-599: 서버 에러

사유 구절

• 응답 시작줄의 마지막 구성요소로, 상태 코드에 대한 글로 된 설명이다.

버전 번호

• HTTP/x.y 형식으로 요청과 응답 메시지 양쪽 모두에 기술된다.
• HTTP 애플리케이션들이 자신이 따르는 프로토콜의 버전을 상대방에게 말해주기 위한 수단이다.

3.2.3 헤더

• HTTP 헤더 필드는 요청과 응답 메시지에 추가 정보를 더한다

헤더 분류

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

헤더를 여러 줄로 나누기

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

3.2.4 엔터티 본문

• 엔터티 본문은 HTTP 메시지의 화물이라고 할 수 있다. 즉 HTTP가 수송하도록 설계된 것들이다.

3.2.5 버전 0.9 메시지

• HTTP/0.9 메시지도 요청과 응답으로 이루어져 있지만, 요청은 그저 메서드와 요청 URL을 갖고 있을 뿐이며, 응답은 오직 엔터티로만 되어있다.
• 이러한 단순함 때문에 다양한 상황에 대응할 수 없으며, 이후 버전에서 생긴 기능들과 애플리케이션들도 구현할 수 없다.
• 하지만 여전히 그것을 사용하는 클라이언트, 서버, 기타 애플리케이션들이 있음을 기억하자.

3.3 메서드

3.3.1 안전한 메서드(Safe Method)

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

3.3.2 GET

• 서버에게 리소스를 달라고 요청하기 위한 메서드이다.

3.3.3 HEAD

• GET처럼 행동하지만, 서버는 응답으로 헤더만을 돌려줄 뿐 엔터티 본문은 반환되지 않는다.
• 이는 클라이언트가 리소스를 실제로 가져올 필요 없이 헤더만을 조사할 수 있도록 해준다.

3.3.4 PUT

• 서버에 문서를 쓰는 메서드로, 요청의 본문을 가지고 요청 URL의 이름대로 새 문서를 만들거나, 이미 URL이 존재한다면 본문을 사용해서 교체한다.
• PUT은 콘텐츠를 변경할 수 있게 해주기 때문에, 많은 웹서버가 PUT을 수행하기 전에 사용자에게 비밀번호를 입력해서 로그인을 하도록 요구할 것이다.

3.3.5 POST

• 서버에 입력 데이터를 전송하기 위한 메서드이다.
• 실제로 HTML 폼을 지원하기 위해 흔히 사용된다.

3.3.6 TRACE

• 클라이언트에게 자신의 요청이 서버에 도달했을 때 어떻게 보이게 되는지 알려준다.
• 이 메서드는 주로 진단을 위해 사용된다.
• TRACE 요청은 어떠한 엔터티 본문도 보낼 수 없다. 응답의 엔터티 본문에는 서버가 받은 요청이 그대로 들어있다.

3.3.7 OPTIONS

• 웹 서버에게 여러 가지 종류의 지원 범위에 대해 물어본다.
• 이 메서드는 여러 리소스에 대해 실제로 접근하지 않고도 그것들을 어떻게 접근하는 것이 최선인지 확인할 수 있는 수단을 클라이언트 애플리케이션에게 제공한다.

3.3.8 DELETE

• 서버에게 요청 URL로 지정한 리소스를 삭제할 것을 요청한다.
• 하지만 클라이언트는 삭제가 수행되는 것을 보장하지 못한다. HTTP 명세는 서버가 클라이언트에게 알리지 않고 요청을 무시하는 것을 허용하기 때문이다.

3.3.9 확장 메서드

• HTTP/1.1 명세에 정의되지 않은 메서드이다.
• 이 메서드는 개발자들에게 그들의 서버가 구현한 HTTP 서비스의 서버가 관리하는 리소스에 대한 능력을 확장하는 수단을 제공한다.
  • LOCK: 사용자가 리소스를 잠글 수 있게 해준다.
  • MKCOL: 사용자가 문서를 생성할 수 있게 해준다.
  • COPY: 서버가 있는 리소스를 복사한다.
  • MOVE: 서버에 있는 리소스를 옮긴다.

3.4 상태 코드

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

3.4.1 100-199 정보성 상태 코드

• 100 Continue: 계속
  
• 101 Swiching Protocols: 프로토콜 전환
  

3.4.2 200-299 성공 상태 코드

• 200 OK: 성공
  
• 201 Created: 작성됨
  
• 202 Accepted: 허용됨
  
• 203 Non-Authoritative Information: 신뢰할 수 없는 정보
• 204 No Content: 내용 없음
  
• 205 Reset Content: 내용 재설정
• 206 Partial Content: 일부 내용
  

3.4.3 300-399 리다이렉션 상태 코드

• 300 Multiple Choices: 여러 선택 항목
  
• 301 Moved Permanently: 영구 이동
  
• 302 Found: 발견함
  
• 303 See Other: 기타 위치 보기
  
• 304 Not Modified: 수정되지 않음
  
• 305 Use Proxy: 프록시 사용
  
• 307 Temporary Redirect: 임시 리다이렉트
  

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

• 400 Bad Request: 잘못된 요청
  
• 401 Unauthorized: 권한 없음
  
• 402 Payment Required: 지불 필요
  
• 403 Forbidden: 금지됨
  
• 404 Not Found: 찾을 수 없음
  
• 405 Method Not Allowed: 허용되지 않은 방법
  
• 406 Not Acceptable: 허용되지 않음
  
• 407 Proxy Authentication Required: 프록시 인증 필요
• 408 Request Time-out: 요청 시간 초과
  
• 409 Conflict: 충돌
  
• 410 Gone: 사라짐
  
• 411 Length Required: 길이 필요
  
• 412 Precondition Failed: 사전 조건 실패
  
• 413 Request Entity Too Large: 요청 속성이 너무 큼
  
• 414 Request-URI Too Large: 요청 URL이 너무 김
  
• 415 Unsupported Media Type: 지원되지 않는 미디어 유형
  
• 416 Requested range not satisfiable: 처리할 수 없는 요청 범위
  
• 417 Expectation Failed: 예상 실패
  

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

• 500 Internal Server Error: 내부 서버 오류
  
• 501 Not Implemented: 구현되지 않음
  
• 502 Bad Gateway: 불량 게이트웨이
  
• 503 Service Unavailable: 서비스 이용 불가
  
• 504 Gateway Time-out: 게이트웨이 시간 초과
  
• 505 HTTP Version not supported: 지원되지 않은 HTTP 버전

3.5 헤더

일반 헤더(General Headers)

• 클라이언트와 서버 양쪽 모두가 사용하는 헤더로, 클라이언트, 서버 그리고 어딘가에 메시지를 보내는 다른 애플리케이션들을 위해 다양한 목적으로 사용된다.

요청 헤더(Request Headers)

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

응답 헤더(Response Headers)

• 클라이언트에게 정보를 제공하기 위한 자신만의 헤더를 갖고 있다.

엔터티 헤더(Entity Headers)

• 엔터니 본문에 대한 헤더

확장 헤더(Extension Headers)

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

📌 데이빗 고울리, 브라이언 토티, 마조리 세이어, 세일루 레디, 안슈 아가왈 공저 이응준, 정상일 공역, 『HTTP 완벽 가이드: 웹은 어떻게 동작하는가』, 인사이트(2014)