(해석 또는 이해가 잘못된 부분이 있다면 댓글로 편하게 알려주세요.)
The previous section focused on the first line of request and response messages (methods, status codes, reason phrases, and version numbers). Following the start line comes a list of zero, one, or many HTTP header fields (see Figure 3-5).
이전 섹션에서는 요청과 응답 메시지의 첫 번째 줄(메소드, 상태 코드, 사유 구절, 버전 번호)을 중점적으로 살펴보았습니다.
스타트라인의 다음 줄에는 0줄 이상의 HTTP 헤더 필드가 등장합니다. (Figure 3-5)
HTTP header fields add additional information to request and response messages. They are basically just lists of name/value pairs. For example, the following header line assigns the value 19 to the Content-Length header field:
Content-length: 19
HTTP 헤더 필드는 요청과 응답 메시지에 대한 부가적인 정보를 제공합니다.
기본적으로 이것은 name/value 쌍의 리스트로 구성됩니다.
예를 들어 다음의 헤더 라인은 Content-length 필드에 19를 값으로 할당하고 있습니다.
Content-length: 19
The HTTP specification defines several header fields. Applications also are free to invent their own home-brewed headers. HTTP headers are classified into:
HTTP 명세에서는 몇 가지 헤더 필드를 정의하고 있습니다.
또한 애플리케이션이 자체적으로 그들만의 home-brewed 헤더를 자유롭게 발명할 수도 있습니다.
HTTP 헤더는 다음과 같이 분류됩니다.
General headers
Can appear in both request and response messages
Request headers
Provide more information about the request
Response headers
Provide more information about the response
Entity headers
Describe body size and contents, or the resource itself
Extension headers
New headers that are not defined in the specification
Each HTTP header has a simple syntax: a name, followed by a colon (:), followed by optional whitespace, followed by the field value, followed by a CRLF. Table 3-4 lists some common header examples.
각각의 HTTP 헤더는 단순한 문법을 가지고 있습니다.
name 다음에 콜론(:)이 오고, 공백 문자를 쓴 다음 value가 뒤따라 옵니다. 그리고 마지막으로 CRLF가 옵니다.
Table 3-4가 몇 가지 일반적인 헤더 예시를 나열하고 있습니다.
Long header lines can be made more readable by breaking them into multiple lines, preceding each extra line with at least one space or tab character.
For example:
HTTP/1.0 200 OK Content-Type: image/gif Content-Length: 8572 Server: Test Server Version 1.0
In this example, the response message contains a Server header whose value is broken into continuation lines. The complete value of the header is “Test Server Version 1.0”.
위의 예시에서 응답 메시지는 "Server" 헤더를 포함하고 있습니다.
이 헤더의 값은 연속 행으로 나누어져 있습니다.
즉 헤더의 완전한 값은 "Test Server Version 1.0"입니다.
We’ll briefly describe all the HTTP headers later in this chapter. We also provide a more detailed reference summary of all the headers in Appendix C.
우리는 모든 HTTP 헤더에 대해 이번 챕터 후반부에서 간단히 알아볼 겁니다.
그리고 모든 헤더에 대한 더 자세한 참고자료는 Appendix C에서 제공됩니다.
The third part of an HTTP message is the optional entity body. Entity bodies are the payload of HTTP messages. They are the things that HTTP was designed to transport.
HTTP 메시지의 세 번째 부분은 부가적인 엔티티 본문입니다.
엔티티 본문은 HTTP 메시지의 페이로드입니다.
** 페이로드 : 데이터 전송에서 유용한 정보를 나타내는 부분
이것은 HTTP가 전송하도록 설계된 것입니다.
HTTP messages can carry many kinds of digital data: images, video, HTML documents, software applications, credit card transactions, electronic mail, and so on.
HTTP 메시지는 다양한 종류의 디지털 정보를 실어 나를 수 있습니다.
이러한 디지털 정보에는 이미지, 비디오, HTML 문서, 소프트웨어 애플리케이션, 신용카드 거래, 전자 메일 등이 있습니다.
HTTP Version 0.9 was an early version of the HTTP protocol. It was the starting point for the request and response messages that HTTP has today, but with a far simpler protocol (see Figure 3-6).
HTTP 버전 0.9는 HTTP 프로토콜의 초기 버전입니다.
이것은 오늘날 HTTP가 가지고 있는 요청과 응답 메시지의 출발점이지만, 훨씬 더 간단한 프로토콜이었습니다. (Figure 3-6)
HTTP/0.9 messages also consisted of requests and responses, but the request contained merely the method and the request URL, and the response contained only the entity. No version information (it was the first and only version at the time), no status code or reason phrase, and no headers were included.
HTTP/0.9 메시지 역시 요청과 응답으로 구성되어 있습니다. 하지만 요청 메시지는 오직 메소드와 요청 URL만을 포함하고, 응답 메시지는 오직 엔티티만을 포함합니다.
버전 정보, 상태 코드나 사유 구절, 헤더는 포함되지 않습니다.
버전 정보가 포함되지 않는 이유는 그 당시 최초의 버전이자 유일한 버전이었기 때문입니다.
However, this simplicity did not allow for much flexibility or the implementation of most of the HTTP features and applications described in this book. We briefly describe it here because there are still clients, servers, and other applications that use it, and application writers should be aware of its limitations.
그러나, 이 책에 나온 것처럼 HTTP의 특성과 애플리케이션을 대부분 구현하거나 더 많은 유연성을 갖기에는 너무 단순했습니다.
간단히 HTTP/0.9에 대해 설명한 까닭은 아직까지 클라이언트와 서버를 비롯한 애플리케이션이 이 버전을 사용하고 있으며, 애플리케이션 개발자가 이러한 한계에 대해 알고 있어야 하기 때문입니다.
** Header Continuation Line : 긴 헤더 라인은 한 개 시앙의 공백 또는 탭 문자를 통해 여러 줄로 나누어 가독성을 높일 수 있다
** 버전 정보, 헤더, 상태 코드, 사유 구절은 포함 X