---

Chapter 3. HTTP Messages

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

---

❤️ 원문 번역 ❤️

Headers

Headers and methods work together to determine what clients and servers do. This section quickly sketches the purposes of the standard HTTP headers and some headers that are not explicitly defined in the HTTP/1.1 specification (RFC 2616). Appendix C summarizes all these headers in more detail.

• 헤더와 메소드는 함께 동작하며 클라이언트와 서버가 수행할 역할을 결정합니다.

• 이번 섹션에서는 표준 HTTP 헤더와 HTTP/1.1 명세(RFC 2616)에 명시되지 않은 몇 가지 헤더의 목적에 대해 정리합니다.

• Appendix C는 이러한 모든 헤더들을 자세히 요약하고 있습니다.

** [1] General Headers는 지난 포스팅에서 확인할 수 있습니다.

---

[2] Request Headers

Request headers are headers that make sense only in a request message. They give information about who or what is sending the request, where the request originated, or what the preferences and capabilities of the client are. Servers can use the information the request headers give them about the client to try to give the client a better response. Table 3-13 lists the request informational headers.

• 요청 헤더는 요청 메시지에만 적합한 헤더입니다.

• 이 헤더는 누가 어떤 요청을 전송했는지, 어디에서 생성된 요청인지, 클라이언트가 어떤 것을 선호하고 어떤 능력이 있는지에 관한 정보를 제공합니다.

• 서버는 클라이언트에게 더 나은 응답을 돌려주기 위해 요청 헤더에 담긴 정보를 활용할 수 있습니다.

• Table 3-13은 요청 정보 헤더를 나열한 것입니다.

Accept headers

Accept headers give the client a way to tell servers their preferences and capabilities: what they want, what they can use, and, most importantly, what they don’t want. Servers can then use this extra information to make more intelligent decisions about what to send. Accept headers benefit both sides of the connection. Clients get what they want, and servers don’t waste their time and bandwidth sending something the client can’t use. Table 3-14 lists the various accept headers.

• Accept 헤더는 클라이언트가 서버에게 그들의 선호와 능력(클라이언트가 무엇을 원하고, 무엇을 사용할 수 있는지, 그리고 가장 중요하게는 무엇을 원하지 않는지)을 전달할 수 있게 합니다.

• 서버는 이러한 부가적인 정보를 사용하여 무엇을 전송할지에 대해 더 현명한 결정을 내릴 수 있습니다.

• Accept 헤더는 연결의 양측 모두에게 도움이 됩니다.

• 클라이언트는 그들이 원하는 것을 돌려받고, 서버는 클라이언트가 사용할 수 없는 것들을 전송하는 데 시간과 대역폭(전송 용량)을 허비하지 않습니다.

• Table 3-14는 다양한 Accept 헤더를 나열한 것입니다.

Conditional request headers

Sometimes, clients want to put some restrictions on a request. For instance, if the client already has a copy of a document, it might want to ask a server to send the document only if it is different from the copy the client already has. Using conditional request headers, clients can put such restrictions on requests, requiring the server to make sure that the conditions are true before satisfying the request. Table 3-15 lists the various conditional request headers.

• 가끔은 클라이언트가 요청에 제한을 두기를 원하기도 합니다.

• 예를 들어 클라이언트가 문서의 사본을 이미 가지고 있다면, 클라이언트는 보유중인 사본과 문서가 다를 때만 서버에게 전송을 요청하고 싶을 겁니다.

• 조건부 요청 헤더를 사용하면 클라이언트는 요청에 이러한 제한을 둘 수 있습니다. 즉 요청을 만족하기 전 조건이 성립하는지를 우선 확인하도록 요청합니다.

• Table 3-15는 다양한 조건부 요청 헤더를 나열한 것입니다.

Request security headers

HTTP natively supports a simple challenge/response authentication scheme for requests. It attempts to make transactions slightly more secure by requiring clients to authenticate themselves before getting access to certain resources. We discuss this challenge/response scheme in Chapter 14, along with other security schemes that have been implemented on top of HTTP. Table 3-16 lists the request security headers.

• HTTP는 기본적으로 요청에 대한 간단한 챌린지/응답 인증 방식을 지원합니다.

• 이것은 클라이언트가 특정 리소스에 접근하기 전 자신을 인증하게 하여 보다 안전한 트랜잭션을 생성하도록 합니다.

• 챌린지/인증 방식에 대해서는 HTTP 위에 구현된 다른 보안 기술과 함께 Chapter 14에서 자세히 이야기합니다.

• Table 3-16은 요청 보안 헤더를 나열한 것입니다.

Proxy request headers

As proxies become increasingly common on the Internet, a few headers have been defined to help them function better. In Chapter 6, we discuss these headers in detail. Table 3-17 lists the proxy request headers.

• 프록시가 인터넷상에서 점점 더 보편적으로 사용됨에 따라 이를 더 잘 기능하도록 도와주는 몇 가지 헤더가 정의되었습니다.

• Chapter 6에서 이러한 헤더들에 대해 자세히 다룹니다.

• Table 3-17은 프록시 요청 헤더들을 나열한 것입니다.

---

🧡 요약 정리 🧡

Headers

• 클라이언트와 서버가 수행할 일을 결정

[2] Request Headers

• 요청 메시지에만 적합한 헤더

• 누가 어떤 요청을 전송했고 이 요청이 어디에서 발생했는지에 관한 정보 포함
  (Client-IP, Host, Referer, User-Agent 등)

• Accept Headers : 클라이언트가 원하는 것과 원하지 않는 것에 대해 명시
  (Accept, Accept-Charset, Accept-Encoding 등)

• Conditional Request Headers : 요청에 제한을 두기 위한 헤더
  (Expect, If-Match, If-Modified-Since 등)

• Request Security Headers : 안전한 트랜잭션을 위해 리소스에 접근하기 전 클라이언트를 인증하는 헤더
  (Autorization, Cookie 등)

• Proxy Request Headers : 프록시의 기능을 돕는 헤더

---

💛 감상 💛

• 이전에 Methods 부분에서 HEAD 메소드에 대해 다루었다. 이 메소드는 리소스의 수정 여부를 확인하는 데에도 종종 사용된다고 했다. 그렇다면 HEAD 요청을 전송하고 리소스가 수정되었을 때만 GET 요청을 전송하는 방식과 그냥 If-Modified-Since를 포함한 GET 요청을 전송하는 방식 중 어떤 것이 더 좋을까? 수정사항이 발생했을 때 반드시 GET을 해야 하는 상황이라면 후자가 편할 것이다. 내가 GET 메소드는 알고 HEAD 메소드는 몰랐다면 수정이 됐거나 말거나 주구장창 트래픽을 주고받았을 것이고, HEAD 메소드를 알지만 조건부 요청 헤더를 몰랐다면 불필요하게 두 번의 요청을 주고받았을 것이다. 아는 만큼 보이고, 생각하는 만큼 나아간다. 내가 두꺼운 전공책을 읽는 이유가 바로 여기에 있지 않을까.