3장 HTTP 메시지

3.1 메시지의 흐름

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

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

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

• HTTP 메시지는 강물과 같이 흐른다.
• 요청이나 응답 상관없이 메시지는 다운스트림으로 흐른다.

3.2 메시지의 각 부분

HTTP 메시지는 시작줄, 헤더, 본문으로 구성된 구조화된 블록이다.

시작줄은 어떤 메시인지 서술하고, 헤더는 속성, 본문은 데이터를 담고 있으며, 본문은 존재하지 않을 수 있다.

3.2.1 메시지 문법

요청메시지 형식

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

<엔터티 본문>

응답메시지 형식

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

<엔터티 본문>

메서드

• 클라이언트가 서버에 리소스 요청 시에 서버가 수행하길 원하는 동작이다.

요청URL

• 리소스를 지칭하는 완전한 URL 혹은 URL의 경로 구성요소다.
• 완전하지 않은 URL이라고 하더라도, 클라이언트와 서버와 직접 대화를 하면서 리소스를 가리키는 절대 경로이기만 하면, 문제가 없다.

버전

• 사용중인 HTTP의 버전이다.
• HTTP/<메이저>.<마이너> 로 구성된다.

상태 코드

• 요청 중에 무엇이 일어났는지 설명하는 세 자리의 숫자다.
• 각 코드의 첫 번째 자릿수는 상태의 일반적인 분류를 나타낸다.

사유 구절(reason-phrase)

• 숫자로 구성된 상태 코드를 사람이 이해 가능하도록 나타내는 짧은 문구이다.

헤더들

• 이름 : 공백 or 값 형태의 순서대로 0개 이상 나타난다.

엔터티 본문

• 임의의 데이터 블록을 포함하지만, 모든 메시지가 엔터티 본문을 갖지 않는다.
• 널리 쓰이는 규칙이나 지키지 않는 구현체와의 호환을 위해, 클라이언트와 서버는 마지막 CRLF(빈줄) 없이 끝나는 메시지도 받아들일 수 있도록 해야 한다.

3.2.2. 시작줄

요청줄

• 서버에게 리소스에 대해 무언가를 해달라고 요청한다.
• 요청 URL, 어떤 동작을 해야하는지에 대한 메서드, HTTP버전을 포함한다.

응답줄

• 수행 결과에 대한 상태 정보와 결과 데이터를 클라이언트에게 돌려준다.
• HTTP버전, 숫자로 된 상태 코드, 수행 상태에 대해 설명해주는 사유구절을 포함한다.

메서드

• 요청의 시작줄은 메서드로 시작하며, 서버가 무엇을 해야하는지 말해준다.

상태코드

• 응답의 시작줄에 위치하며, 클라이언트에게 무엇이 일어났는지 말해준다.
• 현재 버전의 HTTP는 적은 수의 코드만 정의되어 있다.

사유 구절

• 응답 시작줄의 마지막 구성요소로, 상태 코드에 대한 글로 된 설명을 제공한다.
• HTTP 명세는 사유 구절이 어떻게 구성되어야 하는지에 대한 엄격한 규칙이 존재하지 않는다.

버전 번호

• HTTP/x.y 형식으로 요청과 응답 메시지에 모두 존재한다.
• HTTP로 대화하는 애플리케이션들에게 대화 상대의 능력과 메시지의 형식에 대한 단서를 제공해주기 위한것이다.

3.2.3 헤더

• HTTP 헤더는 여러 헤더 필드를 정의한다.

• 애플리케이션은 자유롭게 자신만의 헤더를 만들 수 있다.

  HTTP/1.0 200 OK
  Content-Type: image/gif
  Content-Length: 8572
  Server: Test Server

  Version 1.0

3.2.4 엔터티 본문

• HTTP 메시지의 구성 요소 중 선택적으로 HTTP가 수송하도록 설계된 화물이라고 할 수 있다.
• 이미지, 비디오, HTML문서, 소프트웨어 애플리케이션, 전자우편 등 여러 종류의 디지털 데이터를 실어 나른다.

3.3 메서드

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

3.3.1 안전한 메서드

• GET, HEAD 는 안전한 메서드로 HTTP 요청 후에 서버에서 어떠한 자원의 변경이 일어나지 않는다.

3.3.2 GET

• 가장 흔히 사용되는 메서드로 서버에게 리소스를 달라고 요청시에 사용된다.

3.3.3 HEAD

• GET처럼 행동하지만, 서버는 응답으로 헤더만을 돌려준다.
• 리소스를 가져오지 않고도 그에 대해 무엇인가를 알아 낼 수 있다.
• 응답의 상태 코드를 통해, 개체가 존재하는지 확인 할 수 있다.
• 헤더를 확인하여 리소스가 변경되었는지 검사할 수 있다.

3.3.4 PUT

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

3.3.5 POST

• 서버에 입력 데이터를 전송하기 위해 설계되었다.
• HTML 폼을 지원하며, 담긴 데이터는 서버로 전송된다.

3.3.6 TRACE

• 클라이언트에게 자신의 요청이 서버에 도달했을 때 어떻게 보이게 되는지 알려준다.
• 클라이언트는 자신과 목적지 서버 사이에 있는 모든 HTTP 애플리케이션의 요청/응답 연쇄를 따라가면서 자신이 보낸 메시지가 망가졌거나 수정되었는지, 만약 그렇다면 어떻게 변경되었는지 확인할 수 있다.

3.3.7 OPTIONS

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

3.3.8 DELETE

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

3.4 상태 코드

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

• HTTP/1.1에서 도입되었다.

3.4.2 200-299: 성공 상태 코드

• 클라이언트가 요청을 보내고, 요청이 성공한다.
• 서버는 성공을 의미하는 상태 코드의 배열을 갖고 있으며, 각각의 요청에 대응한다.

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

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

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

• 클라이언트가 서버에게 알 수 없는 요청을 보냈을때 나타난다.

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

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

3.5 헤더

3.5.1 일반 헤더

• 클라이언트와 서버 양쪽 모두가 사용하고 메시지에 대한 아주 기본적인 정보를 제공한다.
• ex)Date: Tue, 3 Oct 1974 02:16:00 GMT

일반 캐시 헤더

HTTP 애플리케이션에게 매번 원 서버로부터 객체를 가져오는 대신, 로컬 복사본으로 캐시할 수 있도록 해준다.

3.5.2 요청 헤더

• 요청 메시지에서만 의미를 갖는다.
• 요청이 최초 발생한 곳에서 누가 혹은 무엇이 그 요철을 보냈는지에 대한 정보나 클라이언트의 선호나 능력에 대한 정보를 제공한다.
• ex)Accept: */*

3.5.3 응답 헤더

• 응답 메시지는 그들만의 응답 헤더를 갖는다.
• 누가 응답을 보내고 있는지, 응답자의 능력은 어떻게 되는지 알려주면, 응답에 대한 특별한 설명도 제공할 수 있다.
• ex)Server: Tiki-Hut/1.0

3.5.4 엔터티 헤더

• 요청과 응답 양 타입의 메시지에 모두 나타날 수 있다.
• 개체의 타입부터 주어진 리소스에 대해 요청할 수 있는 유효한 메서드들까지, 광범위한 정보를 제공한다.
• ex)Content-Type: texthtml; charset=iso-latin-1

3.5.5 확장 헤더

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