이 포스팅은 책 ‘HTTP 완벽가이드’를 읽고 작성하였습니다.
3. HTTP 메시지
3.1 HTTP 메시지의 흐름
HTTP 메시지는 HTTP 애플리케이션 간에 주고받는 데이터의 블록입니다.
이 메시지는 클라이언트, 서버, 프락시 사이를 흐릅니다.
메시지가 흐르는 방향을 인바운드와 아웃바인드로 이름을 붙여 설명하는데 인바운드는 클라이언트에서 서버로 흐르는 메시지를 말하며 아웃바운드는 반대로 서버에서 클라이언트로 흐르는 것을 말힙니다.
3.2 메시지의 각 부분
HTTP 메시지는 단순한, 데이터의 구조화된 블록입니다. 각 메시지는 클라이언트로부터의 요청이나 서버로부터의 응답 중 하나를 포함합니다. 메시지는 시작줄, 헤더 블록, 본문 이렇게 세 부분으로 이루어집니다.
3.2.1 메시지 문법
모든 HTTP 메시지는 요청 메시지나 응답 메시지로 분류됩니다. 요청 메시지는 웹 서버에 어떤 동작을 요구합니다. 응답 메시지는 요청의 결과를 클라이언트에게 돌려줍니다. 요청과 응답 모두 기본적으로 구조가 같습니다.
각 형식은 다음과 같습니다.
- 요청 메시지 형식
<메서드 요청> <URL> <버전>
<헤더>
<엔터티 본문>
- 응답 메시지 형식
<버전> <상태 코드> <사유 구절>
<헤더>
<엔터티 본문>
3.2.2 시작줄
모든 HTTP 메시지는 시작줄로 시작합니다. 요청 메시지의 시작줄은 무엇을 해야하는지 말해줍니다. 응답 메시지의 시작줄은 무슨 일이 일어났는지 말해줍니다.
3.2.3 헤더
HTTP 헤더 필드는 요청과 응답 메시지에 추가 정보를 더합니다. 그들은 기본적으로 이름/값 쌍의 목록입니다. 예를들어, 다음의 헤더줄은 Content-Length 헤더 필드에 19라는 값을 할당합니다.
Content-length: 19
3.2.4 엔터티 본문
HTTP 메시지는 엔터티 본문에 이미지, 비디오, HTML 문서 등 여러 종류의 디지털 데이터를 실어 나를 수 있습니다.
3.3 메서드
3.3.1 GET
GET은 가장 흔히 쓰이는 메서드입니다. 주로 서버에게 리소스를 달라고 요청하기 위해 쓰입니다.
3.3.2 HEAD
서버가 응답으로 헤더만을 돌려줍니다. 엔터티 본문은 반환되지 않습니다. 이는 클라이언트가 리소스를 실제로 가져올 필요 없이 헤더만을 조사할 수 있도록 해줍니다. 이를 사용하면
- 리소스를 가져오지 않고도 그에 대해 무엇인가(타입 등)을 알아낼 수 있습니다.
- 응답의 상태 코드를 통해, 개체가 존재하는지 확인이 가능합니다.
- 헤더를 확인하여 리소스가 변경되었는지 확인할 수 있습니다.
3.3.3 PUT
PUT 메서드는 서버에 문서를 씁니다. 서버가 요청의 본문을 가지고 요청 URL의 이름대로 새 문서를 만들거나, 이미 URL이 존재한다면 본문을 사용해서 교체하는 것입니다.
PUT은 콘텐츠를 변경할 수 있게 해주기 때문에, 사용자에게 비밀번호를 입력하여 로그인을 하도록 요구하기도 합니다.
3.3.4 POST
POST 메서드는 서버에 입력 데이터를 전송하기 위해 설계되었습니다. 실제로는 HTML Form을 지원하기 위해 흔히 사용됩니다. Form의 테이터를 서버로 전송합니다.
3.3.5 TRACE
TRACE 메서드는 클라이언트에게 자신의 요청이 서버에 도달했을 때 어떻게 보이게 되는지 알려줍니다.
이는 서버에 ‘루프백(loopback)’ 진단을 시작합니다. 요청 전송의 마지막 단계의 서버는 자신이 받은 요청 메시지를 본문에 넣어 TRACE 응답을 되돌려줍니다. 클라이언트는 자신과 목적지 사이의 요청/응답 연쇄를 따라가면서 자신이 보낸 메시지가 망가졌는지 수정되었는지를 확인합니다.
3.3.6 OPTIONS
OPTIONS 메서드는 웹 서버에게 여러 가지 종류의 지원 범위에 대해 물어봅니다. 서버에게 특정 리소스에 대해 어떤 메서드가 지원되는지 물어볼 수 있습니다.
3.3.7 DELETE
DELETE 메서드는 서버에게 요청 URL로 지정한 리소스를 삭제할 것을 요청합니다.
3.3.8 확장 메서드
HTTP는 필요에 따라 확장해도 문제가 없도록 되어있습니다. 확장 메서드는 HTTP/1.1 명세에 정의되지 않은 메서드입니다. 이는 개발자들이 자신의 서버의 HTTP 메소드를 확장하여 사용할 수 있도록 해줍니다. 하지만 마음대로 확장 메서드를 사용하게되면 이를 처음 접하는 클라이언트는 어떤 의미인지 모를 수 있습니다. 그런 경우에는 이를 관용적으로 대하는 것이 좋다고합니다. 확장 메서드를 다룰 때는 “엄격하게 보내고 관대하게 받아들여라”라는 오랜 규칙을 따릅니다.
3.4 상태코드
3.4.1 100-199: 정보성 상태 코드
| 상태 코드 | 사유 구절 | 의미 |
|---|---|---|
| 100 | Continue | 요청의 시작 부분 일부가 받아들여졌으며, 클라이언트는 나머지를 계속 이어서 보내야 한다. 이것을 보낸 후, 서버는 반드시 요청을 받아 응답해야 한다. |
| 101 | Switching Protocols | 클라이언트가 Upgrade 헤더에 나열한 것 중 하나로 서버가 프로토콜을 바꾸었음을 의미한다. |
3.4.2 200-299: 성공 상태 코드
| 상태 코드 | 사유 구절 | 의미 |
|---|---|---|
| 200 | OK | 요청 정상 |
| 201 | Created | 서버 개체를 생성하라는 요청(ex. PUT)을 위한 것이다. 서버는 상태 코드를 보내기 전 반드시 객체를 생성해야 한다. |
| 202 | Accepted | 요청은 받아들여졌으나 서버는 아직 어떤 동작도 수행하지 않는다. 요청 처리 완료에 대한 보장도 없다. |
| 204 | No Content | 응답 메시지는 헤더와 상태줄은 포함하지만, 엔터티 본문은 포함하지 않는다. |
| 206 | Partial Content | 부분 혹은 범위 요청이 성공 |
3.4.3 300-399: 리다이렉션 상태 코드
| 상태 코드 | 사유 구절 | 의미 |
|---|---|---|
| 300 | Multiple Choices | 클라이언트가 동시에 여러 리소스를 가리키는 URL을 요청할 경우, 그 리소스의 목록과 함께 반환한다. 사용자는 목록에서 원하는 하나를 선택할 수 있다. |
| 301 | Moved Permanently | 요청한 URL이 옮겨졌을 때 사용함. 응답에 Location 헤더에 현재 리소스의 URL을 포함해야 한다. |
| 302 | Found | 301 상태 코드와 같음. 그러나 Location 헤더로 주어진 URL을 리소스를 임시로 가리키기 위한 목적으로 사용해야 한다. |
| 303 | See Other | 클라이언트에게 리소스를 다른 URL에서 가져와야 한다고 말할 때 사용한다. 새 URL은 응답 메시지의 Location 헤더에 들어있다. |
| 304 | Not Modified | 리소스가 수정되지 않았음을 의미한다. 엔터티 본문을 가져서는 안 된다. |
3.4.4 400-499: 클라이언트 에러 상태 코드
| 상태 코드 | 사유 구절 | 의미 |
|---|---|---|
| 400 | Bad Request | 클라이언트가 잘못된 요청을 보냈다고 말해준다. |
| 401 | Unauthorized | 리소스를 얻기 전에 클라이언트에게 스스로를 인증하라고 요구하는 내용의 응답을 반환한다. |
| 403 | Forbidden | 요청이 서버에 의해 거부되었다. |
| 404 | Not Found | 서버가 요청한 URL을 찾을 수 없다. |
| 408 | Request Timeout | 클라이언트 요청을 완수하는 시간이 오래 걸리는 경우, 이 상태 코드로 응답하고 연결을 끊을 수 있다. |
| 409 | Conflict | 요청이 리소스에 대해 일으킬 수 있는 몇몇 충돌을 지칭하기 위해 사용한다. |
3.4.5 500-599: 서버 에러 상태 코드
| 상태 코드 | 사유 구절 | 의미 |
|---|---|---|
| 500 | Internal Server Error | 서버가 요청을 처리할 수 없는 에러를 만났을 때 사용한다. |
| 501 | Not Implemented | 클라이언트가 서버의 능력을 넘은 요청을 했을 때 사용한다. |
| 502 | Bad Gateway | 프락시나 게이트웨이처럼 행동하는 서버가 그 요청 응답 연쇄에 있는 다음 링크로부터 가짜 응답에 맞닥뜨렸을 때 사용한다. |
| 503 | Service Unavailable | 현재는 서버가 요청을 처리해줄 수 없지만 나중에는 가능하다. |
| 504 | Gateway Timeout | 408과 비슷하지만, 다른 서버에 요청을 보내고 응답을 기다리다 타임아웃이 발생한 게이트웨이나 프락시에서 온 응답이라는 점이 다르다. |
| 505 | HTTP Version Not Supported | 서버가 지원할 수 없거나 지원하지 않으려고 하는 버전의 프로토콜로 된 요청을 받았을 때 사용한다. |
3.5 헤더
헤더와 메서드는 클라이언트와 서버가 무엇을 하는지 결정하기 위해 함께 사용됩니다.
헤더에는 특정 종류의 메시지에만 사용할 수 있는 헤더와, 더 일반 목적으로 사용할 수 있는 헤더, 그리고 응답과 요청 메시지 양쪽 모두에서 정보를 제공하는 헤더가 있습니다.
- 일반 헤더
일반 헤더는 클라이언트와 서버 양쪽 모두가 사용합니다. 예를들어 Date 헤더는 서버와 클라이언트를 가리지 않고 메시지가 만들어진 일시를 지칭하기 위해 사용되는 일반 목적 헤더입니다.Date: Tue, 3 Oct 1974 02:16:00 GMT 요청 헤더
요청 헤더는 요청 메시지를 위한 헤더입니다. 요청이 최초 발생한 곳에서 누가 혹은 무엇이 그 요청을 보냈는지에 대한 정보나 클라이언트의 정보를 줍니다.응답 헤더
응답 헤더는 클라이언트에게 부가 정보를 제공합니다. 누가 응답을 보내고 있는지 혹은 응답자의 능력은 어떻게 되는지 알려주며, 응답에 대한 특별한 설명도 제공합니다.- 엔터티 헤더
요청과 응답 양쪽 모두 엔터티를 포함할 수 있기 때문에 이 헤더들은 양 타입의 메시지에 모두 나타날 수 있습니다. 일반적으로 엔터티 헤더는 메시지의 수신자에게 자신이 다루고 있는 것이 무엇인지 말해줍니다.