HTTP: HTTP 메시지

도서 HTTP 완벽 가이드를 읽고 알게 된 지식을 정리한 글입니다.

---

메시지의 흐름

• 메시지가 서버 방향으로 흐르는 것은 인바운드로 이동하는 것이고, 모든 처리가 끝난 뒤에 클라이언트 방향으로 돌아오는 것은 아웃바운드로 이동하는 것이다.
• 요청·응답 메시지 관계없이 모든 메시지는 다운스트림으로 흐른다.

---

메시지 문법

메시지는 시작줄, 헤더, 본문으로 이뤄진다.

시작줄: 어떤 메시지인지 서술한다.

헤더: 속성 정보를 가진다.

본문: 데이터를 담는다.

---

 

요청 메시지와 응답 메시지 형식

	요청 메시지	응답 메시지
시작줄	<메서드> <요청 URL> <버전>	<버전> <상태 코드> <사유 구절>
헤더	<헤더>	<헤더>
본문	<본문>	<본문>

 

---

메서드

• 요청의 시작줄은 메서드로 시작한다.
• 서버에게 무엇을 해야 하는지 알려준다.
• 메서드에 따라 요청 메시지의 본문 여부가 나뉜다.

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

 

안전한 메서드

• HTTP 요청의 결과로 서버에 어떤 작용도 없는 경우를 안전한 메서드라고 한다.
• GET, HEAD 메서드는 안전하다고 할 수 있다.
• 안전한 메서드의 목적은, 안전하지 않은 메서드가 사용될 때 사용자에게 그 사실을 알려주는 것에 있다.

---

요청 URL

요청 대상이 되는 리소스를 지칭하는 URL이다.

---

상태 코드

• 서버 응답의 시작줄에 포함된다.
• 서버가 클라이언트에게 무슨 일이 일어났는지 말해준다.
• 세 자리 숫자로 된 코드값을 기준으로 묶인다.

 

사유 구절

• 서버 응답 시작줄의 마지막 구성요소이다.
• 상태 코드에 대한 글로 된, 사람이 이해할 수 있는 쉬운 설명을 제공한다.
• 상태 코드와 일대일로 대응된다.
• HTTP 명세는 사유 구절에 대한 명세를 제공하지 않는다. 200 OK와 200 NOT OK는 서버에서 똑같이 취급된다.

 

100-199 정보성 상태 코드

상태 코드	사유 구절	의미
100	Continue	요청의 시작 부분 일부가 받아들여졌으며, 클라이언트는 나머지 부분을 계속 이어서 보내야 한다. 이것을 보낸 서버는 반드시 클라이언트의 요청을 받아 응답해야 한다. 클라이언트의 입장에서 100 Continue 응답을 받고 싶다면, 반드시 값을 100-continue로 하는 Expect 요청 헤더를 보내야 한다. 반대로 엔터티를 보내지 않을 것이라면, 서버의 혼란을 막기 위해 100-continue Expect 헤더를 보내지 않아야 한다. 서버의 입장에서 100-continue 값이 담긴 Expect 헤더가 포함된 요청을 받는다면, 100 Continue 응답 또는 에러 코드로 답해야 한다. 서버는 절대로 이 응답을 받을 것을 의도하지 않은 클라이언트에게 이 응답을 보내서는 안 된다.
101	Switching Protocols	클라이언트가 Upgrade 헤더에 나열한 것 중 하나로 서버가 프로토콜을 바꾸었음을 의미한다.

 

200-299 성공 상태 코드

상태 코드	사유 구절	의미
200	OK	요청은 정상이고, 엔터티 본문은 요청된 리소스를 포함하고 있다.
201	Created	서버 개체를 생성하라는 요청에 따른 응답이다. 생성된 리소스에 대한 최대한 구체적인 참조가 담긴 Location 헤더와 함께, 그 리소스를 참조할 수 있는 여러 URL을 엔터티 본문에 포함해야 한다. 서버는 201 상태 코드를 보내기에 앞서 반드시 객체를 생성해야 한다.
202	Accepted	요청은 받아들여졌으나 서버는 아직 그에 대한 어떤 동작도 수행하지 않았다. 서버가 요청 처리를 완료할 것인지에 대한 어떤 보장도 없고, 단지 요청이 받아들이기에 적합해 보인다는 의미이다. 서버는 엔터티 본문에 요청에 대한 상태와 언제 처리가 완료될지에 대한 추정을 포함해야 한다.
203	Non-Authoritative Information	엔터티 헤더에 들어있는 정보가 원래 서버가 아닌 리소스의 사본에서 왔다. 중개자가 리소스의 사본을 갖고 있었지만 리소스에 대한 헤더를 검증하지 못한 경우 이런 일이 발생할 수 있다. 만약 엔터티 헤더가 원래 서버에서 온 것이었다면 응답이 200 상태였을 것이다.
204	No Content	응답 메시지는 헤더와 상태줄을 포함하지만 엔터티 본문은 포함하지 않는다. 주로 웹 브라우저를 새 문서로 이동시키지 않고 갱신하고자 할 때 사용한다.
205	Reset Content	브라우저에게 현재 페이지에 있는 HTML 폼에 채워진 모든 값을 비우라고 말한다.
206	Partial Content	부분 혹은 범위 요청이 성공했음을 의미한다.

 

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

클라이언트에 관심있어 하는 리소스에 대해 다른 위치를 사용하라고 말해주거나, 그 리소스의 내용 대신 대안 응답을 제공한다. HEAD가 아닌 요청에 대해 리다이렉션 상태 코드를 포함한 응답을 할 때, 리다이렉트될 URL에 대한 링크와 설명을 포함시키면 좋다.

상태 코드	사유 구절	의미
300	Multiple Choices	클라이언트가 동시에 여러 리소스를 가리키는 URL을 요청한 경우, 그 리소스의 목록과 함께 반환한다. 사용자는 목록에서 원하는 하나를 선택할 수 있다.
301	Moved Permanently	요청한 URL이 영구적으로 옮겨졌을 때 사용한다. 응답은 Location 헤더에 현재 리소스가 존재하고 있는 URL을 포함해야 한다.
302	Found	301 상태 코드와 비슷하나, 클라이언트는 Location 헤더로 주어진 URL을 리소스를 임시로 가리키기 위한 목적으로 사용해야 한다. 즉, 이후의 요청에서는 원래 URL을 사용해야 한다.
303	See Other	클라이언트에게 리소스를 다른 URL에서 가져와야 한다고 말해주고자 할 때 쓰인다. 새 URL은 응답 메시지의 Location 헤더에 들어있다. 이 상태 코드의 주 목적은 POST 요청에 대한 응답으로 클라이언트에게 리소스의 위치를 알려주는 것이다.
304	Not Modified	클라이언트는 헤더를 이용해 조건부 요청을 만들 수 있다. 만약 클라이언트가 조건부 GET 요청을 보냈고 그 요청한 리소스가 최근에 수정된 일이 없다면, 이 코드는 리소스가 수정되지 않았음을 의미하게 된다. 응답은 엔터티 본문을 가져서는 안된다.
305	Use Proxy	리소스가 반드시 프락시를 통해서 접근되어야 함을 나타낸다. 프락시의 위치는 Location 헤더를 통해 주어진다. 클라이언트는 모든 요청에 대해 이 프락시를 통해야 한다고 생각하지 않고, 주어진 특정 리소스에 대해서만 이 프락시를 통해야 한다고 생각한다.
306	Temporary Redirect	301 상태 코드와 비슷하다. 그러나 클라이언트는 Location 헤더로 주어진 URL을 리소스를 임시로 가리키기 위한 목적으로 사용해야 한다. 이후의 요청에서는 원래 URL을 사용해야 한다.

 

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

상태 코드	사유 구절	의미
400	Bad Request	클라이언트의 요청이 잘못되었다.
401	Unauthorized	리소스를 얻기 전에 클라이언트를 인증하라고 요구하는 내용의 응답을 적절한 헤더와 함께 반환한다.
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	404와 비슷하나, 서버가 한때 그 리소스를 가지고 있었다는 점에서 다르다. 주로 웹 사이트를 유지보수하면서 리소스가 제거된 경우 이를 알려주기 위해 사용한다.
411	Length Required	서버가 요청 메시지에 Content-Length 헤더를 요구할 때 사용한다.
412	Precondition Failed	클라이언트가 조건부 요청을 했는데 그중 하나가 실패했을 때 사용한다. 조건부 요청은 클라이언트가 Expect 헤더를 포함했을 때 발생한다.
413	Request Entity To Large	서버가 처리할 수 있는, 혹은 처리하고자 하는 한계를 넘은 크기의 요청을 클라이언트가 보냈을 때 사용한다.
414	Request Entity To Long	서버가 처리할 수 있는, 혹은 처리하고자 하는 한계를 넘은 길이의 요청 URL이 포함된 요청을 클라이언트가 보냈을 때 사용한다.
415	Unsupported Media Type	서버가 이해하거나 지원하지 못하는 내용 유형의 엔터티를 클라이언트가 보냈을 때 사용한다.
416	Request Range Not Satisfiable	요청 메시지가 리소스의 특정 범위를 요청했는데, 그 범위가 잘못되었거나 맞지 않을 때 사용한다.
417	Expectation Failed	요청에 포함된 Expect 요청 헤더에 서버가 만족시킬 수 없는 기대가 담겨있는 경우 사용한다. 프락시나 다른 중개 애플리케이션은 원 서버가 요청의 기대를 만족시킬 수 없을 명확한 증거를 가지고 있다면 이 응답 코드를 전송할 수 있다.

 

500-599 서버 에러 상태 코드

상태 코드	사유 구절	의미
500	Internal Server Error	서버가 요청을 처리할 수 없게 만드는 에러를 만났을 때 사용한다.
501	Not Implemented	클라이언트가 서버의 능력을 넘은 요청을 했을 때 사용한다. 예: 서버가 지원하지 않는 메서드 요청
502	Bad Gateway	프락시나 게이트웨이처럼 행동하는 서버가 그 요청 응답 연쇄에 있는 다음 링크로부터 가짜 응답에 맞닥뜨렸을 때 사용한다. 예: 서버가 자신의 부모 게이트웨이에 접속하는 것이 불가능할 때
503	Service Unavailable	현재는 서버가 요청을 처리해줄 수 없지만 나중에는 가능할 때 사용한다. 만약 서버가 언제 그 리소스를 사용할 수 있게 될지 알고 있다면, Retry-After 헤더를 응답에 포함시킬 수 있다.
504	Gateway Timeout	상태 코드 408과 비슷하지만, 다른 서버에게 요청을 보내고 응답을 기다리다 타임아웃이 발생한 게이트웨이나 프락시에서 온 응답이라는 점이 다르다.
505	HTTP Version Not Supported	서버가 지원할 수 없거나 지원하지 않으려고 하는 버전의 프로토콜로 된 요청을 받았을 때 사용한다. 몇몇 서버 애플리케이션의 경우 오래된 버전의 프로토콜은 지원하지 않기도 한다.

 

---

버전 번호

• HTTP/x.y 형식으로 요청과 응답 메시지 모두에 기술된다.
• HTTP 애플리케이션들이 자신이 따르는 프로토콜의 버전을 상대방에게 말해주기 위한 수단이 된다.
• HTTP로 대화하는 애플리케이션들에게 대화 상대의 능력과 메시지의 형식에 대한 단서를 제공해준다. 예를 들어, 버전 1.1 애플리케이션은 버전 2의 새로운 기능을 사용할 수 없다.
• 어떤 애플리케이션이 지원하는 가장 높은 HTTP 버전을 가리킨다.

 

---

헤더

• 이름/값 쌍의 목록을 가진다.
• 요청과 응답 메시지에 추가 정보를 더한다.

 

일반 헤더

• 클라이언트, 서버, 그 외 다른 애플리케이션들을 위해 다양한 목적으로 사용한다.
• Date 헤더: 메시지가 만들어진 일시를 지칭하기 위해 사용한다.

 

요청 헤더

• 요청 메시지를 위한 헤더로, 요청에 대한 부가 정보를 제공한다.
• Accept 헤더: 클라이언트가 자신의 요청에 대응하는 특정 데이터 타입을 받아들일 것임을 의미한다.

 

응답 헤더

• 클라이언트에게 정보를 제공하기 위한 헤더이다.
• Server 헤더: 어떤 서버의 어떤 버전과 대화하고 있음을 말해준다.

 

엔터티 헤더

• 엔터티 본문에 대한 헤더를 말한다.
• 본문 크기와 콘텐츠, 혹은 리소스 그 자체를 기술한다.
• Content-Type 헤더: 이 본문이 어떤 종류의 객체인지 말해준다.

 

확장 헤더

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

 

---

엔터티 본문

• HTTP의 화물이라 할 수 있다.
• 이미지, 비디오, HTML 문서, 소프트웨어 애플리케이션 등 여러 종류의 디지털 데이터를 실어 나를 수 있다.

---