---

Chapter 3. HTTP Messages

(해석 또는 이해가 잘못된 부분이 있다면 댓글로 편하게 알려주세요.)

---

❤️ 원문 번역 ❤️

Start Lines

All HTTP messages begin with a start line. The start line for a request message says what to do. The start line for a response message says what happened.

• 모든 HTTP 메시지는 스타트라인으로 시작됩니다.

• 요청 메시지의 스타트라인은 무엇을 해야 하는지를 나타냅니다.

• 응답 메시지의 스타트라인은 무슨 일이 발생했는지를 나타냅니다.

---

[1] Request Line

Request messages ask servers to do something to a resource. The start line for a request message, or request line, contains a method describing what operation the server should perform and a request URL describing the resource on which to perform the method. The request line also includes an HTTP version which tells the server what dialect of HTTP the client is speaking.

• 요청 메시지는 서버에게 리소스에 대해 수행해야 할 일을 요청합니다.

• 요청 메시지의 스타트라인(혹은 요청 라인)에는 서버가 어떤 동작을 수행해야 하는지를 나타내는 "메소드"와 해당 메소드가 수행되는 리소스를 나타내는 "요청 URL"이 포함되어 있습니다.

• 또한 요청 라인은 클라이언트가 사용하고 있는 HTTP가 무엇인지 서버에게 알려주는 HTTP 버전을 포함하고 있습니다.

All of these fields are separated by whitespace. In Figure 3-5a, the request method is GET, the request URL is /test/hi-there.txt, and the version is HTTP/1.1. Prior to HTTP/1.0, request lines were not required to contain an HTTP version.

• 이 모든 필드들은 공백 문자에 의해 구분됩니다.

• Figure 3-5a에서, 요청 메소드는 GET이고 요청 URL은 /test/hi-there.txt, 버전은 HTTP/1.1입니다.
  (Figure 3-5는 포스팅 상단에 첨부하였습니다)

• HTTP/1.0 이전에는 요청 라인에 HTTP 버전이 요구되지 않았습니다.
  ㅤ

[2] Response Line

Response messages carry status information and any resulting data from an operation back to a client. The start line for a response message, or response line, contains the HTTP version that the response message is using, a numeric status code, and a textual reason phrase describing the status of the operation.

• 응답 메시지는 상태 정보와 모든 동작 결과를 클라이언트에게 되돌려줍니다.

• 응답 메시지의 스타트라인(혹은 응답 라인)은 응답 메시지가 사용중인 HTTP 버전과 숫자로 이루어진 상태 코드, 동작의 상태를 나타내는 텍스트 사유 구절을 포함합니다.

All these fields are separated by whitespace. In Figure 3-5b, the HTTP version is HTTP/1.0, the status code is 200 (indicating success), and the reason phrase is OK, meaning the document was returned successfully. Prior to HTTP/1.0, responses were not required to contain a response line.

• 이 모든 필드들은 공백 문자에 의해 구분됩니다.

• Figure 3-5b에서, HTTP 버전은 HTTP/1.0이고 상태 코드는 200(성공), 사유 구절은 문서가 성공적으로 반환되었음을 드러내는 "OK"입니다.
  (Figure 3-5는 포스팅 상단에 첨부하였습니다)

• HTTP/1.0 이전에는 응답에서 응답 라인이 요구되지 않았습니다.

ㅤ

[3] Methods

The method begins the start line of requests, telling the server what to do. For example, in the line “GET /specials/saw-blade.gif HTTP/1.0,” the method is GET.

• 요청 메시지의 스타트라인은 메소드로 시작됩니다. 메소드는 서버에게 무엇을 해야 하는지를 알려줍니다.

• 예를 들어, "GET /specials/saw-blade.gif HTTP/1.0"에서 메소드는 "GET"입니다.

The HTTP specifications have defined a set of common request methods. For example, the GET method gets a document from a server, the POST method sends data to a server for processing, and the OPTIONS method determines the general capabilities of a web server or the capabilities of a web server for a specific resource.

• HTTP 명세에서는 일반적인 요청 메소드의 집합을 정의합니다.

• 예를 들어, GET 메소드는 서버로부터 문서를 가져옵니다.

• POST 메소드는 서버에게 프로세싱을 위한 데이터를 전송합니다.

• OPTIONS 메소드는 일반적인 웹 서버의 성능을 결정하거나 특정 리소스에 대한 웹 서버의 성능을 결정합니다.

Table 3-1 describes seven of these methods. Note that some methods have a body in the request message, and other methods have bodyless requests.

• Table 3-1은 이 중 일곱 가지 메소드를 나타냅니다.

• 어떤 메소드는 요청 메시지에 본문을 포함하지만 어떤 메소드는 본문을 포함하지 않는다는 것에 유념하기 바랍니다.

Not all servers implement all seven of the methods in Table 3-1. Furthermore, because HTTP was designed to be easily extensible, other servers may implement their own request methods in addition to these. These additional methods are called extension methods, because they extend the HTTP specification.

• 모든 서버가 Table 3-1의 모든 일곱 가지 메소드를 구현하는 것은 아닙니다.

• 게다가 HTTP는 쉽게 확장할 수 있도록 설계되었기 때문에 이러한 메소드 외에도 다른 서버에서 자체적으로 요청 메소드를 구현할 수 있습니다.

• 이와 같은 추가적인 메소드를 확장 메소드라고 부릅니다. HTTP의 규격을 확장하기 때문입니다.
  ㅤ

[4] Status Codes

As methods tell the server what to do, status codes tell the client what happened. Status codes live in the start lines of responses. For example, in the line “HTTP/1.0 200 OK,” the status code is 200.

• 메소드가 서버에게 해야 할 일을 전달하듯, 상태 코드는 클라이언트에게 무슨 일이 발생했는지를 전달합니다.

• 상태 코드는 응답 메시지의 스타트라인에 위치합니다.

• 예를 들어, "HTTP/1.0 200 OK"에서 상태 코드는 "200"입니다.

When clients send request messages to an HTTP server, many things can happen. If you are fortunate, the request will complete successfully. You might not always be so lucky. The server may tell you that the resource you requested could not be found, that you don’t have permission to access the resource, or perhaps that the resource has moved someplace else.

• 클라이언트가 HTTP 서버에게 요청 메시지를 전송할 때 많은 일들이 발생할 . 수있습니다.

• 운이 좋다면 요청이 성공적으로 완료될 것입니다.

• 그러나 항상 운이 좋은 것은 아닐지도 모릅니다.

• 서버는 요청받은 리소스를 찾을 수 없다거나, 리소스에 접근 권한이 없다고 이야기할 수도 있습니다. 혹은 리소스의 위치가 변경된 것 같다고 이야기할 수도 있습니다.

Status codes are returned in the start line of each response message. Both a numeric and a human-readable status are returned. The numeric code makes error processing easy for programs, while the reason phrase is easily understood by humans.

• 상태 코드는 각각의 응답 메시지의 스타트라인에서 반환됩니다.

• 이때 숫자로 나타낸 상태와 텍스트로 나타낸 상태 모두 반환됩니다.

• 숫자 코드는 프로그램의 오류 처리를 쉽게 해주는 반면, 사유 구절은 사람이 쉽게 이해할 수 있게 합니다.

The different status codes are grouped into classes by their three-digit numeric codes. Status codes between 200 and 299 represent success. Codes between 300 and 399 indicate that the resource has been moved. Codes between 400 and 499 mean that the client did something wrong in the request. Codes between 500 and 599 mean something went awry on the server.

• 서로 다른 상태 코드들은 세 자리수 숫자 코드에 의해 몇 가지 종류로 나누어집니다.

• 200에서 299 사이의 상태 코드는 성공을 나타냅니다.

• 300에서 399 사이의 상태 코드는 리소스의 위치가 바뀌었음을 나타냅니다.

• 400에서 499 사이의 상태 코드는 클라이언트의 요청이 어딘가 잘못되었음을 나타냅니다.

• 500에서 599 사이의 상태 코드는 서버에 문제가 있음을 나타냅니다.

The status code classes are shown in Table 3-2.

• 상태 코드의 몇 가지 종류가 Table 3-2에 있습니다.

Current versions of HTTP define only a few codes for each status category. As the protocol evolves, more status codes will be defined officially in the HTTP specification. If you receive a status code that you don’t recognize, chances are someone has defined it as an extension to the current protocol. You should treat it as a general member of the class whose range it falls into.

• HTTP의 현재 버전에서는 각 상태 카테고리에 몇 안 되는 코드만이 정의되어 있습니다.

• 프로토콜이 진화함에 따라 더 많은 상태 코드가 HTTP 명세에 공식적으로 정의될 것입니다.

• 만약 여러분이 인식하지 못하는 상태 코드를 받아들였다면, 누군가가 현재의 프로토콜의 확장으로 그것을 정의했을 가능성이 있습니다.

• 여러분은 그것을 해당 범위에 속한 카테고리의 일반적인 구성 요소로 받아들여야 합니다.

For example, if you receive status code 515 (which is outside of the defined range for 5XX codes listed in Table 3-2), you should treat the response as indicating a server error, which is the general class of 5XX messages.

• 예를 들어 여러분이 상태 코드 515(5XX 코드의 정의 범위에서 벗어난 것)를 받았다면, 여러분은 해당 응답이 5XX 메시지의 일반적인 특징인 서버 오류를 나타내는 것으로 받아들여야 합니다.

Table 3-3 lists some of the most common status codes that you will see. We will explain all the current HTTP status codes in detail later in this chapter.

• Table 3-3은 여러분이 보게 될 가장 흔히 사용되는 상태 코드의 목록입니다.

• 현존하는 모든 HTTP 상태 코드는 이 챕터의 후반부에서 상세 설명합니다.

ㅤ

[5] Reason Phrases

The reason phrase is the last component of the start line of the response. It provides a textual explanation of the status code. For example, in the line “HTTP/1.0 200 OK,” the reason phrase is OK.

• 사유 구절은 응답 메시지의 스타트라인의 마지막 구성 요소입니다.

• 이것은 상태 코드에 대한 설명을 텍스트로 제공합니다.

• 예를 들어, "HTTP/1.0 200 OK"에서 사유 구절은 "OK"입니다.

Reason phrases are paired one-to-one with status codes. The reason phrase provides a human-readable version of the status code that application developers can pass along to their users to indicate what happened during the request.

• 사유 구절은 상태 코드와 일대일로 쌍을 이룹니다.

• 사유 구절은 상태 코드를 사람이 읽을 수 있는 형태로 제공합니다. 따라서 애플리케이션 개발자가 요청을 수행하는 동안 발생한 일을 나타내기 위해 유저들에게 사유 구절을 전달할 수 있습니다.

The HTTP specification does not provide any hard and fast rules for what reason phrases should look like. Later in this chapter, we list the status codes and some suggested reason phrases.

• HTTP 명세는 사유 구절의 형태에 대해 엄격하고 신속한 규정을 제공하지 않습니다.

• 이 챕터의 후반부에서, 상태 코드와 몇 가지 제안되는 사유 구절에 대해 열거합니다.

ㅤ

[6] Version Numbers

Version numbers appear in both request and response message start lines in the format HTTP/x.y. They provide a means for HTTP applications to tell each other what version of the protocol they conform to.

• 버전 번호는 HTTP/x.y의 형태로 요청 메시지와 응답 메시지의 스타트라인에 모두 나타납니다.

• 이것은 HTTP 애플리케이션이 어떤 버전의 프로토콜을 준수하는지 서로 알 수 있게 하는 수단을 제공합니다.

Version numbers are intended to provide applications speaking HTTP with a clue about each other’s capabilities and the format of the message. An HTTP Version 1.2 application communicating with an HTTP Version 1.1 application should know that it should not use any new 1.2 features, as they likely are not implemented by the application speaking the older version of the protocol.

• 버전 번호는 HTTP를 준수하는 애플리케이션에게 서로의 능력과 메시지의 형태에 대한 단서를 제공하도록 설계되었습니다.

• HTTP 버전 1.1 애플리케이션과 통신하는 HTTP 버전 1.2 애플리케이션은 1.2의 모든 새로운 특성을 사용하면 안 된다는 것을 알아야 합니다. 구버전의 프로토콜을 사용하는 애플리케이션에는 그러한 요소들이 구현되지 않았을 가능성이 있기 때문입니다.

The version number indicates the highest version of HTTP that an application supports. In some cases this leads to confusion between applications,* because HTTP/1.0 applications interpret a response with HTTP/1.1 in it to indicate that the response is a 1.1 response, when in fact that’s just the level of protocol used by the responding application.

• 버전 번호는 애플리케이션이 지원하는 HTTP의 최상위 버전을 나타냅니다.

• 어떤 상황에서 이것은 애플리케이션 사이에 혼란을 야기하기도 합니다.

• HTTP/1.0 애플리케이션이 HTTP/1.1이 포함된 응답을 해석하여 그 응답이 1.1 응답임을 나타낸다고 오해할 수 있기 때문입니다.

• 그러나 버전 번호는 그저 응답 애플리케이션에 의해 사용되는 프로토콜의 수준을 나타낼 뿐입니다.

Note that version numbers are not treated as fractional numbers. Each number in the version (for example, the “1” and “0” in HTTP/1.0) is treated as a separate number. So, when comparing HTTP versions, each number must be compared separately in order to determine which is the higher version. For example, HTTP/2.22 is a higher version than HTTP/2.3, because 22 is a larger number than 3.

• 또한 버전 번호가 소수가 아님에 유의합니다.

• 버전의 각 숫자(예를 들어 HTTP/1.0의 "1"과 "0")는 별개의 숫자입니다.

• 따라서 HTTP 버전을 비교할 때, 각각의 숫자들은 어떤 것이 더 상위 버전인지 결정하기 위해 따로 비교되어야 합니다.

• 예를 들어 HTTP/2.22는 HTTP/2.3보다 상위 버전입니다. 22가 3보다 . 큰 숫자기 때문입니다.

---

🧡 요약 정리 🧡

Start Lines

• 요청 메시지 : 무엇을 해야 하는가

  <method> <request-URL> <version>

• 응답 메시지 : 무엇을 했는가

  <version> <status> <reason-phrase>

1. Methods

• 서버가 해야 할 일을 명시하는 부분
  

2. Status Codes

• 클라이언트에게 무슨 일이 발생했는지 전달하는 부분
  

3. Reason Phrases

• 상태 코드에 대한 텍스트 설명

4. Version Numbers

• 애플리케이션이 준수하는 HTTP의 최상위 버전
• 애플리케이션 사이에서 서로의 능력과 메시지의 형태에 대한 단서 제공
• HTTP/x.y 의 형태
  (단, x.y는 소수가 아니다 -> x와 y는 별개의 숫자로 해석)

---

💛 감상 💛

• Start Lines가 4페이지에 걸쳐 있어서 평소보다 많은 분량을 읽었다. 시간이 조금 오래 걸렸지만 다른 날보다 많이 읽고 심지어 꼼꼼하게 정리한 것 같아서 뿌듯하다.

• Version Number가 애플리케이션이 준수하는 HTTP의 최상위 버전인지는 처음 알았다. 나는 버전 번호가 단순히 현재 통신하고 있는 HTTP의 버전이라고만 생각했다. 기존의 생각을 고수했다면 저자가 지적한 부분을 평생 이해하지 못했을 것이다. 이렇게 하나 또 새롭게 배워간다.