---

Chapter 3. HTTP Messages

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

---

❤️ 원문 번역 ❤️

Status Codes

HTTP status codes are classified into five broad categories, as shown earlier in Table 3-2. This section summarizes the HTTP status codes for each of the five classes.

• HTTP 상태 코드는 앞서 Table 3-2에서 본 것처럼 5가지의 카테고리로 광범위하게 나누어집니다.

• 이번 섹션에서는 다섯 가지 분류 각각의 HTTP 상태 코드를 요약합니다.

The status codes provide an easy way for clients to understand the results of their transactions. In this section, we also list example reason phrases, though there is no real guidance on the exact text for reason phrases. We include the recommended reason phrases from the HTTP/1.1 specification.

• 상태 코드는 클라이언트가 트랜잭션의 결과를 이해하기 쉽게 만듭니다.

• 이번 섹션에서는 사유 구절의 예시 또한 살펴볼 겁니다. 다만 사유 구절에는 실제 가이드라인이 존재하지 않습니다.

• 이 책은 HTTP/1.1의 명세에서 몇 가지 추천되는 사유 구절을 포함합니다.

---

100-199 : Informational Status Codes

HTTP/1.1 introduced the informational status codes to the protocol. They are relatively new and subject to a bit of controversy about their complexity and perceived value. Table 3-6 lists the defined informational status codes.

• HTTP/1.1은 정보를 제공하는 상태 코드를 도입합니다.

• 정보 상태 코드는 상대적으로 새롭고, 복잡성과 인식되는 가치 측면에서 약간의 논란이 있습니다.

• Table 3-6은 정의된 정보 상태 코드를 나열한 것입니다.

The 100 Continue status code, in particular, is a bit confusing. It’s intended to optimize the case where an HTTP client application has an entity body to send to a server but wants to check that the server will accept the entity before it sends it. We discuss it here in a bit more detail (how it interacts with clients, servers, and proxies) because it tends to confuse HTTP programmers.

• 이 중에서 특히 100 Continue 상태 코드는 약간 혼란스럽습니다.

• HTTP 클라이언트 애플리케이션이 서버에 전송하고자 하는 엔티티 본문을 가지고 있지만, 이것을 전송하기 전 서버가 엔티티를 승인할 것인지 확인하기를 원하는 경우가 존재할 수 있습니다. 100 Continue는 이런 상황의 최적화를 위해 고안되었습니다.

• 해당 상태 코드가 HTTP 개발자들을 혼란스럽게 하는 면이 있으므로, 이에 대해 더 자세히 (클라이언트, 서버, 프록시와 상호작용하는 방식을) 알아봅시다.
  ㅤ

Clients and 100 Continue

If a client is sending an entity to a server and is willing to wait for a 100 Continue response before it sends the entity, the client needs to send an Expect request header (see Appendix C) with the value 100-continue. If the client is not sending an entity, it shouldn’t send a 100-continue Expect header, because this will only confuse the server into thinking that the client might be sending an entity.

• 만약 클라이언트가 서버에게 엔티티를 전송하고 있고 엔티티를 전송하기 전에 100 Continue 응답을 기다리고자 한다면, 클라이언트는 100-continue를 값으로 갖는 Expect 요청 헤더를 전송해야 합니다. (Appendix C 참조)

• 반면 클라이언트가 엔티티를 전송하고 있지 않다면, 100-continue Expect 헤더를 전송해서는 안 됩니다. 이러한 행위는 서버에게 클라이언트가 엔티티를 전송할 수도 있다는 착각을 유발할 수 있기 때문입니다.

100-continue, in many ways, is an optimization. A client application should really use 100-continue only to avoid sending a server a large entity that the server will not be able to handle or use.

• 100-continue는 여러 면에서 최적화 기법입니다.

• 클라이언트 애플리케이션은 서버가 처리하거나 사용할 수 없다고 예상되는 큰 엔티티를 서버에게 전송하지 않기 위해서만 100-continue를 사용해야 합니다.

Because of the initial confusion around the 100 Continue status (and given some of the older implementations out there), clients that send an Expect header for 100- continue should not wait forever for the server to send a 100 Continue response. After some timeout, the client should just send the entity.

• 100 Continue 상태를 둘러싼 초기의 혼란으로 인해(그리고 일부 오래된 구현들을 고려할 때), 100-continue Expect 헤더를 전송하는 클라이언트는 서버가 100 Continue 응답을 전송하기를 영원히 기다려서는 안 됩니다.

• 특정 시간이 지난 후에 클라이언트는 엔티티를 전송해야 합니다.

In practice, client implementors also should be prepared to deal with unexpected 100 Continue responses (annoying, but true). Some errant HTTP applications send this code inappropriately.

• 실제로 클라이언트를 구현하는 사람들은 예상치 못한 100 Continue 응답을 처리할 준비를 해야 합니다.

• 일부 잘못된 HTTP 애플리케이션은 부적절하게 해당 코드를 전송하기도 합니다.
  ㅤ

Servers and 100 Continue

If a server receives a request with the Expect header and 100-continue value, it should respond with either the 100 Continue response or an error code (see Table 3-9). Servers should never send a 100 Continue status code to clients that do not send the 100- continue expectation. However, as we noted above, some errant servers do this.

• 서버는 100-continue Expect 헤더를 가진 요청을 받으면, 100 Continue 응답이나 에러 코드로 응답해야 합니다. (Table 3-9)

• 서버는 기댓값으로 100-continue를 전송하지 않은 클라이언트에게는 100 Continue 상태 코드를 절대로 전송해서는 안 됩니다.

• 그러나 위에서 언급했던 것처럼 일부 잘못된 서버들이 이런 행위를 합니다.

If for some reason the server receives some (or all) of the entity before it has had a chance to send a 100 Continue response, it does not need to send this status code, because the client already has decided to continue. When the server is done reading the request, however, it still needs to send a final status code for the request (it can just skip the 100 Continue status).

• 서버가 모종의 이유로 100 Continue 응답을 전송할 기회가 생기기도 전에 엔티티 일부(혹은 전체)를 받아버린 경우에는 상태 코드를 전송할 필요가 없습니다. 클라이언트는 이미 계속해서 전송하기로 결정했기 때문입니다.

• 그러나 서버가 요청을 모두 다 읽었을 때에는 여전히 요청에 대한 최종 상태 코드를 전송해야 합니다. (100 Continue 상태는 스킵될 수 있습니다)

Finally, if a server receives a request with a 100-continue expectation and it decides to end the request before it has read the entity body (e.g., because an error has occurred), it should not just send a response and close the connection, as this can prevent the client from receiving the response (see “TCP close and reset errors” in Chapter 4).

• 마지막으로 서버가 100-continue 요청을 받고 엔티티 본문을 읽기 전 해당 요청을 종료하기로 결정했다면, 응답을 보내고 연결을 종료해서는 안 됩니다. 이러한 행위는 클라이언트가 응답을 받는 것을 막을 수도 있습니다. (Chapter 4의 "TCP close and reset errors" 참조)
  ㅤ

Proxies and 100 Continue

A proxy that receives from a client a request that contains the 100-continue expectation needs to do a few things. If the proxy either knows that the next-hop server (discussed in Chapter 6) is HTTP/1.1-compliant or does not know what version the next-hop server is compliant with, it should forward the request with the Expect header in it. If it knows that the next-hop server is compliant with a version of HTTP earlier than 1.1, it should respond with the 417 Expectation Failed error.

• 클라이언트로부터 100-continue 기댓값을 포함한 요청을 받은 프록시는 몇 가지 행동을 취해야 합니다.

• 프록시는 (Chapter 6에서 다룰) next-hop 서버가 HTTP/1.1을 준수한다는 사실을 알거나 next-hop 서버가 준수하는 버전이 무엇인지 알 수 없다면, Expect 헤더를 포함한 요청을 포워딩(전송)해야 합니다.

• 만약 next-hop 서버가 1.1보다 오래된 버전을 준수한다는 사실을 알고 있다면, 프록시는 417 Expectation Failed 에러로 응답해야 합니다.

If a proxy decides to include an Expect header and 100-continue value in its request on behalf of a client that is compliant with HTTP/1.0 or earlier, it should not forward the 100 Continue response (if it receives one from the server) to the client, because the client won’t know what to make of it.

• HTTP/1.0 혹은 그보다 오래된 버전을 준수하는 클라이언트를 대신하여 프록시가 해당 요청에서 100-continue Expect 헤더를 포함하기로 결정한다면, 100 Continue 응답을 클라이언트에게 포워딩해서는 안됩니다(서버로부터 응답을 받은 경우). 클라이언트가 이 응답을 어떻게 처리할지 모르기 때문입니다.

It can pay for proxies to maintain some state about next-hop servers and the versions of HTTP they support (at least for servers that have received recent requests), so they can better handle requests received with a 100-continue expectation.

• next-hop 서버와 지원하는 HTTP 버전에 대해 특정 상태를 유지하기 위해 (적어도 최근에 요청을 받은 서버에 한해서는) 프록시에 대한 비용을 지불할 수 있습니다.

• 따라서 프록시는 100-continue 기댓값을 받은 요청을 보다 잘 처리할 수 있습니다.

---

🧡 요약 정리 🧡

100-199 : Informational Status Codes

[1] 100 Continue

• 엔티티를 전송하기 전 서버가 엔티티를 승인할 것인지 확인하는 상태 코드

  Client

  (1) (전송중) 100-continue를 값으로 갖는 Expect 요청 헤더 전송
  (2) (전송중 X) Expect 요청 헤더 전송 금지

  Server

  (1) 클라이언트가 Expect 요청 X : 100 Continue 상태 코드 전송 금지
  (2) 100 Continue 응답 전 엔티티 수신 : 최종 상태 코드만 전송
  (3) 엔티티 본문 읽기 전 요청 종료 결정 : 응답 보내고 연결 종료 금지

  Proxy

  (1) (요청) next-hop 버전 알 수 없음 : Expect 헤더 포함한 요청 포워딩
  (2) (응답) next-hop <= HTTP/1.1 : 417 Expectation Failed
  (3) (응답) 클라이언트 <= HTTP/1.1 : 100 Continue 포워딩 금지

[2] 101 Switching Protocols

• 클라이언트의 요청대로 서버의 프로토콜이 변경됨을 나타내는 상태 코드
• Upgrade 헤더를 통해 프로토콜 명시

---

💛 감상 💛

• 100번대 상태 코드는 마주할 일이 없다보니 내용이 많이 어렵게 느껴졌다. 글로만 설명이 되어있고 플로우차트 같은 것도 나와있지 않아서 헷갈리는 부분이 많았다.

• 처음 글을 읽을 때 next-hop 서버가 뭔지 몰라서 챗지피티한테 물어봤는데 너무 단순해서 민망할 정도였다. 그냥 "다음 전달될 서버"였던 것이다.... 단순하긴 단순하지만, 번역은 어떻게 해야 할지 여전히 모르겠어서 그냥 next-hop 서버라고 썼다.

• Chapter 3가 끝나면 지금까지 공부한 내용들을 한 번 싹 깔끔하게 정리하고 갈 필요가 있을 것 같다. 머릿속이 뒤죽박죽이 되기 시작했다.