Chapter 3. HTTP Messages
(해석 또는 이해가 잘못된 부분이 있다면 댓글로 편하게 알려주세요.)
❤️ 원문 번역 ❤️
Message Syntax
All HTTP messages fall into two types: request messages and response messages. Request messages request an action from a web server. Response messages carry results of a request back to a client. Both request and response messages have the same basic message structure. Figure 3-4 shows request and response messages to get a GIF image.
-
모든 HTTP 메시지는 요청 메시지와 응답 메시지의 두 가지 유형으로 나뉩니다.
-
요청 메시지는 웹 서버에게 특정 액션을 요청합니다.
-
응답 메시지는 요청의 결과를 클라이언트에게 전달합니다.
-
두 메시지는 모두 동일한 기본 구조를 가지고 있습니다.
-
Figure 3-4는 GIF 이미지를 주고받기 위한 요청 및 응답 메시지를 나타냅니다.
Here’s the format for a request message:
<method> <request-URL> <version> <headers> <entity-body>
- 요청 메시지의 형태는 위와 같습니다.
Here’s the format for a response message (note that the syntax differs only in the start line):
<version> <status> <reason-phrase> <headers> <entity-body>
- 응답 메시지의 형태는 위와 같습니다.
Here’s a quick description of the various parts:
- 각 부분에 대하여 간략하게 설명하겠습니다.
method
The action that the client wants the server to perform on the resource. It is a single word, like “GET,” “HEAD,” or “POST”. We cover the method in detail later in this chapter.
- method (메소드)
- 클라이언트의 입장에서 서버가 리소스에 대해 수행하기를 바라는 액션입니다.
- 메소드는 "GET", "HEAD", "POST"와 같은 하나의 단어입니다.
- 메소드에 대해서는 이번 챕터의 후반부에서 자세히 다룹니다.
request-URL
A complete URL naming the requested resource, or the path component of the URL. If you are talking directly to the server, the path component of the URL is usually okay as long as it is the absolute path to the resource—the server can assume itself as the host/port of the URL. Chapter 2 covers URL syntax in detail.
- request-URL (요청 URL)
- 요청받은 리소스를 명명하는 완전한 URL이나 URL의 Path 구성 요소입니다.
- 서버와 직접 통신하는 경우, URL의 Path 구성 요소는 일반적으로 리소스의 절대적인 Path라면 괜찮습니다. 서버는 자기 자신을 URL의 호스트와 포트라고 가정할 수 있습니다.
- URL Syntax는 Chapter 2에 자세히 언급되어 있습니다.
version
The version of HTTP that the message is using. Its format looks like:
HTTP/<major>.<minor>where major and minor both are integers. We discuss HTTP versioning a bit more later in this chapter.
- version (버전)
- 메시지가 현재 사용중인 HTTP의 버전입니다.
- 형태는HTTP/<major>.<minor>입니다.
- 여기서 major와 minor는 정수입니다.
- HTTP의 버전에 대해서는 이 챕터의 후반부에서 조금 더 다룰 것입니다.
status-code
A three-digit number describing what happened during the request. The first digit of each code describes the general class of status (“success,” “error,” etc.). An exhaustive list of status codes defined in the HTTP specification and their meanings is provided later in this chapter.
- status-code (상태 코드)
- 요청이 진행되는 동안 발생한 일을 묘사하는 세 자리수 숫자입니다.
- 각 코드의 백의 자리 숫자는 "성공", "실패"와 같은 전반적인 분류를 나타냅니다.
- HTTP 명세에 정의된 상태 코드 리스트와 그것의 의미는 이 챕터의 후반부에서 제공됩니다.
reason-phrase
A human-readable version of the numeric status code, consisting of all the text until the end-of-line sequence. Example reason phrases for all the status codes defined in the HTTP specification are provided later in this chapter. The reason phrase is meant solely for human consumption, so, for example, response lines containing “HTTP/1.0 200 NOT OK” and “HTTP/1.0 200 OK” should be treated as equivalent success indications, despite the reason phrases suggesting otherwise.
- reason-phrase (사유 구절)
- 숫자로 된 상태 코드를 사람이 읽을 수 있게 풀어 쓴 버전입니다.
- end-of-line sequence가 등장할 때까지 모두 텍스트로 구성됩니다.
- HTTP 명세에 정의된 모든 상태 코드에 대한 사유 구절은 이 챕터의 후반부에서 제공됩니다.
- 사유 구절은 오직 인간을 위한 것입니다. 따라서 사유 구절이 서로 다른 문구를 제안하더라도, "HTTP/1.0 200 NOT OK"와 "HTTP/1.0 200 OK"를 포함하는 응답 라인들은 똑같이 "성공"을 나타냅니다.
headers
Zero or more headers, each of which is a name, followed by a colon (:), followed by optional whitespace, followed by a value, followed by a CRLF. The headers are terminated by a blank line (CRLF), marking the end of the list of headers and the beginning of the entity body. Some versions of HTTP, such as HTTP/1.1, require certain headers to be present for the request or response message to be valid. The various HTTP headers are covered later in this chapter.
- headers (헤더)
- 헤더는 존재하지 않을 수도 있습니다.
- 한 줄 이상의 헤더에는 각각의 줄이 name, 콜론(:), 공백, value, CRLF순으로 이루어져 있습니다.
- 헤더는 헤더 리스트의 끝과 entity body(엔티티 본문)의 시작을 나타내는 공백 라인(CRLF)에 의해 종료됩니다.
- HTTP/1.1을 비롯한 HTTP의 일부 버전들은 요청이나 응답 메시지가 유효하게 하기 위해 특정 헤더를 요구합니다.
- 다양한 HTTP의 헤더는 이 챕터의 후반부에서 다룰 예정입니다.
entity-body
The entity body contains a block of arbitrary data. Not all messages contain entity bodies, so sometimes a message terminates with a bare CRLF. We discuss entities in detail in Chapter 15.
- entity-body (엔티티 본문)
- 엔티티 본문은 임의의 데이터 블록을 포함합니다.
- 모든 메시지가 본문을 포함하는 것은 아닙니다. 때로는 CRLF만으로 메시지가 종료되기도 합니다.
- 엔티티에 대해서는 Chapter 15에서 자세히 이야기합니다.
Figure 3-5 demonstrates hypothetical request and response messages.
- Figure 3-5는 가상의 요청과 응답 메시지를 나타냅니다.
Note that a set of HTTP headers should always end in a blank line (bare CRLF), even if there are no headers and even if there is no entity body. Historically, however, many clients and servers (mistakenly) omitted the final CRLF if there was no entity body. To interoperate with these popular but noncompliant implementations, clients and servers should accept messages that end without the final CRLF.
-
헤더가 없거나 엔티티 본문이 없더라도, HTTP 헤더는 항상 공백 라인 (CRLF)로 끝나야 한다는 것에 주의합니다.
-
그러나 역사적으로 많은 클라이언트와 서버가 엔티티 본문이 없을 때 마지막 CRLF를 실수로 생략하였습니다.
-
이처럼 자주 사용되지만 어설픈 구현과 상호 소통하기 위해서는 클라이언트와 서버가 마지막 CRLF가 없는 메시지도 받아들일 수 있어야 합니다.
🧡 요약 정리 🧡
Request Message Format
<method> <request-URL> <version>
<headers>
<entity-body>Response Message Format
<version> <status> <reason-phrase>
<headers>
<entity-body>Message Components
- Method : 서버가 리소스에 대해 수행하기를 바라는 액션 (GET, HEAD, POST 등)
- Request-URL : 완전한 URL 혹은 Path 구성 요소
- Version : 메시지가 현재 사용중인 HTTP의 버전
- Status : 요청이 진행되는 동안 발생한 일을 나타내는 세 자릿수 숫자
- Reason-phrase : 상태 코드를 텍스트로 풀어 설명한 것
- Headers : 0줄 이상의 {name}: {value} CRLF 쌍
- Entity-body : 0줄 이상의 임의의 데이터 블록
💛 감상 💛
-
설 연휴를 거하게 쉬고 왔더니 일과 공부가 손에 안 잡힌다. 항상 긴 휴가를 보내고 오면 원래의 페이스를 잃어버리는 느낌이다. 그렇지만 휴가에 쉬어야지 일을 할 수도 없고...ㅎ 그냥 다시 부지런히 감을 찾는 수밖에 없겠다.
-
이번 챕터부터는 본격적으로 요청 메시지와 응답 메시지의 형태에 대해 살핀다. 평소에 스프링부트로 API를 이것저것 만드는 취미가 있는데, 사실 API를 개발하면서 수도 없이 많이 접했던 내용이다. 알던 내용이지만 한 번 더 살펴보면서 놓치고 있는 부분은 없는지 꼼꼼히 확인하려 한다.
