[이번 장에서 배울 것]

• 메시지가 어떻게 흘러가는가
• HTTP 메시지의 세 부분(시작줄, 헤더, 개체 본문)
• 요청과 응답 메시지의 차이
• 요청 메시지가 지원하는 여러 기능(메서드)들
• 응답 메시지가 반환하는 여러 상태 코드들
• 여러 HTTP 헤더들은 무슨 일을 하는가

3.1 메시지의 흐름

HTTP 메시지란? HTTP 애플리ㅔ이션 간에 주고받은 데이터 블록들.
이 메시지는 클라이언트, 서버, 프락시 사이를 흐르며 인바운드, 아웃바운드, 업스트림, 다운스트림의 메시지 방향을 가진다.

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

인바운드와 아웃바운드는 트랜잭션 방향을 표현.
메시지가 원 서버로 이동하는 것을(서버 방향) 인바운드로 이동, 사용자 에이전트로 돌아오는 것을 아웃바운드로 이동한다고 표현한다.

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

HTTP 메시지는 마치 강물과 같이 항상 다운스트림으로 흐른다. 요청 메시지냐 응답 메시지냐에 따라 관계 없이 항상 메시지의 발송자는 수신자의 업스트림이 된다.

3.2 메시지의 각 부분

메시지는 시작줄, 헤더 블록, 본문 이렇게 세 부분으로 이뤄진다.

• 시작줄 : 이것이 어떤 메시지인지 서술
• 헤더 블록 : 속성을 나타냄
  • Content-Type : 본문이 무엇인지 나타낸다. (ex. text/plain)
  • Content-Length : 본문의 크기
• 본문 : 데이터(텍스트나 이진 데이터)를 담고 있으며, 아예 없을 수도 있다.

시작줄과 헤더는 CRLF(줄바꿈)으로 끝난다.

3.2.1 메시지 문법

모든 HTTP 메시지는 요청 메시지와 응답 메시지로 분류된다.

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

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

<엔터티본문>

• 메서드 : 클라이언트 측에서 서버가 리소스에 대해 수행해주길 바라는 동작(ex. GET, POST, HEAD)
• 요청 URL : 요청 대상이 되는 리소스르 ㄹ지칭
• 버전 : 메시지에서 사용 중인 HTTP 버전

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

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

<엔터티 본문>

• 상태 코드 : 요청 중에 무엇이 일어났는지 설명하는 세자리 숫자
• 사유 구절 : 상태코드를 사람이 이해할 수 있게 설명해주는 짧은 문구. 사유 구절의 내용은 오로지 사람을 위한 것으로, 사유 구절이 전혀 달라도 상태 코드가 같다면 똑같이 동작한다.
• 헤더들 : 헤더의 목록은 빈 줄로 끝나 헤더 목록의 끝과 엔터티 본문의 시작을 구분한다.
• 엔터티 본문 : 임의의 데이터 블록을 포함한다.

헤더나 엔터티 본문이 없어도 헤더 집합은 항상 빈 줄(CRLF)로 끝나야 한다. 잘 지켜지지 않는 경우 호환을 위해 CRLF 없이 끝나는 메시지도 받아들일 수 있어야 한다.

3.2.2 시작줄

요청 메시지의 시작줄은 무엇을 해야하는지 말해주고, 응답 메시지의 시작줄은 무슨 일이 일어났는지 말해준다.

요청줄

요청 메시지의 시작줄. 서버에게 어떤 동작이 일어나야 하는지 설명해주는 메서드와 그 동작에 대한 대상을 지칭하는 요청 URL이 들어 있고 HTTP 버전도 포함된다.

응답줄

응답 메시지에 쓰인 HTTP 의 버전, 상태코드, 사유구절이 들어 있다.

메서드

요청줄은 메서드로 시작하고, 서버에게 무엇을 해야하는지 말해준다.

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

HTTP는 쉽게 확장할 수 있기 때문에 서버에 따라 확장 메서드(메서드를 추가로 구현)를 구현할 수 있다.

상태코드

응답 메시지의 시작줄에 위치한다.

• 100~101 : 정보
• 200~206 : 성공
• 300~305 : 리다이렉션
• 400~415 : 클라이언트 에러
• 500~505 : 서버 에러

공식적이지 않은, 프로토콜의 확장으로 인해 정의된 상태코드를 받게 되더라도 그것이 포함되는 범주의 상태코드로 가정하고 다루어야 한다.(ex. 515받으면 5XX, 즉 서버 에러로)

사유 구절

응답줄의 마지막 구성요소. 사람이 이해하기 쉬운 버전의 상태코드로, 규칙이 없다.

버전 번호

HTTP/x.y 형식. 요청과 응답 메시지 모두에 기술. HTTP 애플리케이션들이 자신이 따르는 프로토콜 버전을 상대방에게 말해주기 위한 수단이다.
HTTP/1.1은 HTTP/1.0을 포함한 HTTP/1.1까지 이해할 수 있다는 뜻

3.2.3 헤더

이름/값 쌍의 목록

헤더 분류

• 일반 헤더 : 요청 & 응답 모두 가능
• 요청 헤더 : 요청에 대한 부가 정보 제공
• 응답 헤더 : 응답에 대한 부가 정보 제공
• Entity 헤더 : 본문의 크기와 콘텐츠 혹은 리소스 그 자체를 서술
• 확장 헤더 : 명세에 정의되지 않은 새로운 헤더

3.2.4 엔터티 본문

HTTP 메시지의 세번째 부분. 선택적(없을수도 있다).
이미지, 비디오, HTML 문서, 소프트웨어 어플리케이션, 신용카드 트랜잭션, 전자우편 등 여러 종류의 디지털 데이터 실어 나를 수 있다.

3.3 메서드

3.3.1 안전한 메서드

GET, HEAD를 안전한 메서드라 부른다. 서버에 어떤 작용도 없음(HTTP 요청의 결과로 인해 서버에서 일어나는 일이 없다)을 의미한다.
안전한 메서드의 목적은, 안전하지 않은 메서드 사용 시 이를 사용자에게 알려줄 수 있도록 하기 위함이다. (ex. 온라인 쇼핑에서 구매 버튼을 눌러 POST 요청이 전송된 경우, 신용카드가 결제된다는 것을 알림)

3.3.2 GET

주로 서버에게 리소스를 달라고 요청하기 위해 사용된다.

3.3.3 HEAD

GET처럼 행동하지만, 서버는 응답으로 헤더만을 돌려주고 엔터티 본문을 돌려주지 않는다. 이를 사용하면

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

3.3.4 PUT

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

3.3.5 POST

서버에 입력 데이터를 전송하기 위해 설계되었다. HTML 폼을 지원하기 위해 흔히 사용된다.

POST는 서버에 데이터를 보내기 위함, PUT은 서버에 있는 리소스(파일 등)에 데이터를 입력하기 위함

3.3.6 TRACE

클라이언트가 어떤 요청을 할 때 방화벽, 프락시, 게이트웨이 등의 애플리케이션을 통과할 수 있는데 TRACE 메서드는 클라이언트에게 자신의 요청이 서버에 도달했을 때 어떻게 보이게 되는지를 알려준다.
TRACE는 주로 진단을 위해 사용되며, 프락시나 다른 애플리케이션들이 요청에 어떤 영향을 미치는지도 알 수 있다.
단, 메서드를 구별하는 메커니즘을 제공하지 않아 어떻게 TRACE 요청을 처리할 것인지에 대해선 일반적으로 중간 애플리케이션이 결정한다. (예를 들어, 프락시는 POST 요청은 바로 서버로 통과시키지만, GET은 웹캐시와 같은 다른 HTTP 애플리케이션으로 전송한다.)

3.3.7 OPTIONS

웹 서버에게 여러 가지 종류의 지원 범위에 대해 물어본다. 서버에게 특정 리소스에 대해 어떤 메서드가 지원되는지 물어볼 수 있다.
리소스에 실제로 접근하지 않아도 그것들에 어떻게 접근하는 것이 최선인지 확인할 수 있는 수단을 제공한다.

3.3.8 DELETE

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

3.3.9 확장 메서드

필요에 따라 확장해도 문제가 없다. 새로 기능을 추가해도 과거에 구현된 소프트웨어들의 오작동을 유발하지 않는다. 예를 들어 LOCK, MKCOL, COPY, MOVE와 같은 웹 배포 확장 메소드들이 있다. 확장 메서드는 관용적인 것이 좋다.

3.4 상태 코드

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

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

HTTP/1.1에서 도입.

100 Continue

Continue. 요청의 시작 부분 일부가 받아들여지고, 클라이언트는 나머지를 계속 이어서 보내야 함을 의미한다. 이것을 보낸 후 서버는 반드시 요청을 받아 응답해야 한다.
100 Continue는 HTTP 클라이언트 애플리케이션이 서버에 엔티티 본문을 전송하기 전에 그 엔티티 본문을 서버가 받아들일 것인지 확인하려고 할 때 확인 작업을 최적하기 위한 의도로 도입되었다.

3.4.2 200-299 : 성공 상태 코드

• 200 OK : 요청은 정상, 엔티티 본문은 요청된 리소스를 포함
• 201 Created : 서버 개체를 생성하라는 요청(ex.PUT)을 위한 것. Location 헤더와 함께 리소스를 참조할 수 있는 여러 URL을 엔터티 본문에 포함한다. 상태 코드를 보내기에 앞서 서버는 반드시 객체를 생성해야 한다.
• 202 Accepted : 요청은 받아들여졌으나 서버는 아직 그에 대한 어떤 동작을 수행하지 않았다.(처리 완료에 대한 보장 x)
• 203 Non-Authoritative Information : 엔터티 헤더에 들어있는 정보가 원래 서버가 아닌 리소스의 사본에서 왔다. (리소스에 대한 메타 정보를 검증하지 못한 경우에 발생할 수 있다.) 원래 서버에서 왔더라면 200이었을 것임
• 204 No Content : 응답 메시지는 헤더와 상태줄을 포함하지만 엔터티 본문은 x. 주로 웹브라우저를 새문서로 이동시키지 않고 갱신하고자 할 때 사용된다. (ex. 폼을 리프레쉬)
• 205 Reset Content : 주로 브라우저를 위해 사용되는 또 하나의 코드. 브라우저에게 현재 페이지에 있는 HTML 폼에 채워진 모든 값을 비우도록 한다.
• 206 Partial Content : 부분 혹은 범위 요청이 성공했다.

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

클라이언트가 관심있어 하는 리소스에 대해 다른 위치를 사용하라고 말해주거나 그 리소스의 내용 대신 다른 대안 응답을 제공한다.
만약 리소스가 옮겨졌으면 어디서 찾을 수 있는지 리다이렉션 상태코드와 Location 헤더를 선택적으로 보낼 수 있다.
리소스에 대한 애플리케이션의 로컬 복사본이 원래 서버와 비교했을 때 유효한지 확인하기 위해 사용되기도 한다. (304 Not Modified)

• 300 Multiple Choices : 클라이언트가 동시에 여러 리소스를 가리키는 URL을 요청한 경우 그 리소스의 목록과 함께 반환한다. 사용자는 원하는 하나를 선택할 수 있다. (ex. HTML 문서를 영어와 프랑스어 모두 제공하는 경우)
• 301 Moved Permanently : 요청한 URL이 옮겨진 경우
• 302 Found : 301 과 같지만, 클라이언트는 Location 헤더로 주어진 url 을 리소스를 임시로 가리키기 위한 목적으로 사용해야 하며 이후의 요청에서는 원래 url 사용.
• 303 See Other : 리소스를 다른 URL에서 가져와야 하는 경우. POST 요청에 대한 응답으로 리소스의 위치를 알려줄 때 주로 사용된다.
• 304 Not Modified : GET 과 같은 조건부 요청을 보냈고 그 요청한 리소스가 최근에 수정된 일이 없다면, 이 코드는 리소스가 수정되지 않았음을 의미한다.
• 305 Use Proxy : 특정 리소스가 반드시 프락시를 통해서 접근되어야 함을 의미한다.
• 306 : 사용x
• 307 Temporary Redirect : 301과 비슷. 그러나 Loaction 헤더로 주어진 URL을 리소스를 임시로 가리키기 위한 목적으로 사용한다. 이후에는 원래 URL 사용

302, 303, 307 상태코드가 중복되는 부분이 있다. 이는 주로 HTTP/1.0과 HTTP/1.1이 이 상태 코드를 다루는 방식의 차이점에 기인한다.
결국 서버는 리다이렉트 응답에 들어갈 가장 적절한 리다이렉트 상태 코드를 선택하기 위해 클라이언트의 HTTP 버전을 검사할 필요가 있다.

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

클라이언트가 서버가 다룰 수 없는 무엇인가로 보내는 경우이다.

• 400 Bad Request : 클라이언트가 잘못된 요청을 보냄
• 401 Unauthorized : 리소스를 얻기 전에 클라이언트에게 스스로를 인증하라는 요구
• 402 Payment Required : 현재는 사용되지 않고 미래에 사용될 가능성
• 403 Forbidden : 요청이 서버에 의해 거부됨. 보통 서버가 거절의 이유를 숨기고 싶을 때 사용한다.
• 404 Not Found : 서버가 요청한 URL을 찾을 수 없음을 알려주기 위함
• 405 Method Not Allowed : 요청한 URL에 대해 지원하지 않는 메소드로 요청받았을 때 사용한다. 어떤 메서드가 사용한지 알려주기 위해 응답에 Allow헤더를 포함한다.
• 406 Not Acceptable : 클라이언트는 자신이 어떤 종류의 엔터티를 받아들이고자 하는지 명시할 수 있는데 주어진 URL에 대한 리소스 중 클라이언트가 받아들일 수 있는 것이 없는 경우에 사용된다.
• 407 Proxy Authentication Required : 401과 같지만 리소스에 대해 인증을 요구하는 프락시 서버를 위해 사용된다.

이외에 408 Request Timeout, 409 Conflict, 410 Gone, 411 Length Required, 412 Precondition Failed, 413 Request Entity Too Large, 414 Request URI Too Long, 415 Unsupported Media Type, 416 Requested Range Not Satisfiable, 417 Expectation Failed 등이 있다.

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

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

• 500 Interal Server Error : 서버가 요청을 처리할 수 없게 만드는 에러를 만난 경우
• 501 Not Implemented : 클라이언트가 서버의 능력을 넘은 요청을 한 경우
• 502 Bad Gateway : 프락시나 게이트웨이처럼 행동하는 서버가 그 요청 응답 연쇄에 있는 다음 링크로부터 가짜 응답에 맞닥뜨렸을 때
• 503 Service Unavailable : 현재는 서버가 요청을 처리해줄 수 없지만 나중에는 가능함
• 504 Gateway Timeout : 다른 서버에게 요청을 보내고 응답을 기다리다가 타임아웃이 발생한 게이터웨이나 프락시로 부터 온 응답
• 505 HTTP Version Not Supported : 서버가 지원할 수 없거나 지원하지 않으려고 하는 버전의 프로토콜로 온 요청을 받았을 때

3.5 헤더

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

일반헤더

클라이언트와 서버 모두 사용. 다양한 목적으로 사용
Date 등이 있다.

요청헤더

요청 메시지를 위한 헤더. 서버에게 클라이언트가 받고자 하는 데이터 타입이 무엇인지와 같은 부가 정보를 제공.
Accept 등이 있다.

응답헤더

응답 메시지를 위한 헤더. 클라이언트에게 정보를 제공하기 위함. 예를 들어 클라이언트가 어떤 종류의 서버와 대화하고 있는가를 나타낸다.
예를 들어 Server 등이 있다.

엔터티헤더

엔터티 본문에 대한 헤더. 예를 들어 엔터티 헤더는 엔터티 본문에 있는 데이터 타입이 무엇인지 말해줄 수 있다.
Content-Type 등이 있다.

확장헤더

비표준 헤더