---

Chapter 5. Web Servers

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

---

❤️ 원문 번역 ❤️

Step 5: Building Responses

Once the web server has identified the resource, it performs the action described in the request method and returns the response message. The response message contains a response status code, response headers, and a response body if one was gener- ated. HTTP response codes were detailed in “Status Codes” in Chapter 3.

• 웹 서버는 리소스를 식별한 후 요청 메소드에 나타난 액션을 수행하여 응답 메시지를 반환합니다.

• 생성된 응답 메시지에는 응답 상태 코드, 응답 헤더, 응답 본문이 포함되어 있습니다.

• HTTP 응답 코드는 Chapter 3의 "Status Codes"에 자세히 기술되어 있습니다.

Response Entities

If the transaction generated a response body, the content is sent back with the response message. If there was a body, the response message usually contains:

• A Content-Type header, describing the MIME type of the response body
• A Content-Length header, describing the size of the response body
• The actual message body content

• 만약 트랜잭션이 응답 본문을 생성한다면 콘텐츠가 응답 메시지와 함께 수신됩니다.

• 본문이 존재할 때 응답 메시지는 일반적으로 다음과 같은 것들을 포함합니다.
  - 응답 본문의 MIME 타입을 나타내는 Content-Type 헤더
  - 응답 본문의 크기를 나타내는 Content-Length 헤더
  - 실제 응답 본문 콘텐츠

MIME Typing

The web server is responsible for determining the MIME type of the response body. There are many ways to configure servers to associate MIME types with resources:

• 웹 서버는 응답 본문의 MIME 타입을 결정해야 합니다.

• 리소스에 MIME 타입을 할당하도록 서버를 구성하는 방법에는 여러 가지가 있습니다.

mime.types

The web server can use the extension of the filename to indicate MIME type. The web server scans a file containing MIME types for each extension to compute the MIME type for each resource. This extension-based type association is the most common; it is illustrated in Figure 5-12.

Mime.Types

• 웹 서버는 MIME 타입을 나타내기 위해 파일명의 확장자를 사용할 수 있습니다.

• 웹 서버는 각각의 확장자에 대하여 MIME 타입을 포함한 파일을 스캔하여 리소스에 대한 MIME 타입을 계산합니다.

• 이러한 확장자 기반의 타입은 가장 일반적인 할당 방법입니다. Figure 5-12에 그 과정이 나타나 있습니다.

Magic typing

The Apache web server can scan the contents of each resource and pattern- match the content against a table of known patterns (called the magic file) to determine the MIME type for each file. This can be slow, but it is convenient, especially if the files are named without standard extensions.

Magic Typing

• Apache 웹 서버는 각 리소스 콘텐츠를 스캔하고 "magic file"이라 불리는 이미 알려진 패턴의 테이블에 콘텐츠를 매칭하여 각 파일에 대한 MIME 타입을 결정합니다.

• 이것은 특히 파일이 표준 확장자 없이 명명된 상황에서 느리지만 편리합니다.

Explicit typing

Web servers can be configured to force particular files or directory contents to have a MIME type, regardless of the file extension or contents.

Explicit Typing

• 웹 서버는 파일의 확장자나 콘텐츠에 관계없이 특정 파일이나 디렉토리 콘텐츠가 강제로 MIME 타입을 갖도록 구성할 수 있습니다.

Type negotiation

Some web servers can be configured to store a resource in multiple document formats. In this case, the web server can be configured to determine the “best” format to use (and the associated MIME type) by a negotiation process with the user. We’ll discuss this in Chapter 17.

• 일부 웹 서버는 다중의 문서 포맷에 리소스를 저장하도록 구성할 수 있습니다.

• 이러한 경우 웹 서버는 사용자와의 협상 과정을 통해 사용할 최적의 포맷을 결정하도록 구성됩니다.

• Type Negotiation은 Chapter 17에서 자세히 다룹니다.

Web servers also can be configured to associate particular files with MIME types.

• 웹 서버가 특정 파일에 MIME 타입을 할당하도록 구성될 수도 있습니다.

---

Redirection

Web servers sometimes return redirection responses instead of success messages. A web server can redirect the browser to go elsewhere to perform the request. A redirection response is indicated by a 3XX return code. The Location response header contains a URI for the new or preferred location of the content. Redirects are useful for:

• 웹 서버는 종종 성공 메시지 대신 리디렉션 응답을 반환하기도 합니다.

• 웹 서버는 요청을 수행하기 위해 브라우저를 다른 곳으로 리디렉션할 수 있습니다.

• 리디렉션 응답은 3XX 상태 코드로 나타납니다.

• Location 응답 헤더는 콘텐츠의 새로운 혹은 권장되는 위치의 URI를 포함합니다.

• 리디렉션은 다음과 같은 상황에 유용합니다.

Permanently moved resources

A resource might have been moved to a new location, or otherwise renamed, giving it a new URL. The web server can tell the client that the resource has been renamed, and the client can update any bookmarks, etc. before fetching the resource from its new location. The status code 301 Moved Permanently is used for this kind of redirect.

Permanently Moved Resources

• 리소스가 새로운 위치로 이동하거나 이름이 변경되었을 때 새로운 URL을 부여했을 수도 있습니다.

• 웹 서버는 클라이언트에게 리소스의 이름이 변경되었음을 알릴 수 있고, 클라이언트는 새로운 위치에서 리소스를 가져오기 전 임의의 북마크를 업데이트할 수 있습니다.

• 301 Move Permanently 상태 코드가 이러한 유형의 리디렉트에 사용됩니다.

Temporarily moved resources

If a resource is temporarily moved or renamed, the server may want to redirect the client to the new location. But, because the renaming is temporary, the server wants the client to come back with the old URL in the future and not to update any bookmarks. The status codes 303 See Other and 307 Temporary Redirect are used for this kind of redirect.

Temporarily Moved Resources

• 만약 리소스가 임시로 이동하거나 개명되었다면 서버는 클라이언트가 새로운 위치로 리디렉션하기를 바랄 것입니다.

• 그러나 이것은 일시적인 변경이므로, 서버는 클라이언트가 다음부터 원래의 URL로 접속하고 북마크를 업데이트하지 않기를 바랍니다.

• 303 See Other 상태 코드와 307 Temporary Redirect 상태 코드가 이러한 유형의 리디렉트에 사용됩니다.

URL augmentation

Servers often use redirects to rewrite URLs, often to embed context. When the request arrives, the server generates a new URL containing embedded state information and redirects the user to this new URL.* The client follows the redirect, reissuing the request, but now including the full, state-augmented URL. This is a useful way of maintaining state across transactions. The status codes 303 See Other and 307 Temporary Redirect are used for this kind of redirect.

URL Augmentation

• 서버는 종종 URL을 재작성하여 컨텍스트를 포함하기 위해 리디렉션을 사용합니다.

• 요청이 도착했을 때 서버는 임베딩된 상태 정보를 포함하는 새로운 URL을 생성하고 유저를 새로운 URL로 리디렉션합니다.

• 클라이언트는 리디렉션을 따라 요청을 재발행하지만 이제 완전한 state-augmented URL을 포함합니다.

• 이것은 트랜잭션 과정에서 상태 정보를 유지하는 데 유용한 방법입니다.

• 303 See Other와 307 Temporary Redirect 상태 코드가 이러한 유형의 리디렉트에 사용됩니다.

Load balancing

If an overloaded server gets a request, the server can redirect the client to a less heavily loaded server. The status codes 303 See Other and 307 Temporary Redirect are used for this kind of redirect.

Load Balancing

• 과부하에 걸린 서버가 요청을 받으면 클라이언트를 아직 과부하에 걸리지 않은 서버로 리디렉션합니다.

• 303 See Other와 307 Temporary Redirect 상태 코드가 이러한 유형의 리디렉트에 사용됩니다.

Server affinity

Web servers may have local information for certain users; a server can redirect the client to a server that contains information about the client. The status codes 303 See Other and 307 Temporary Redirect are used for this kind of redirect.

Server Affinity

• 웹 서버는 특정 유저에 대한 로컬 정보를 가지고 있을 수도 있습니다.

• 이 서버는 클라이언트에 대한 정보를 포함하고 있는 서버로 클라이언트를 리디렉션할 수 있습니다.

• 303 See Other와 307 Temporary Redirect 상태 코드가 이러한 유형의 리디렉트에 사용됩니다.

Canonicalizing directory names

When a client requests a URI for a directory name without a trailing slash, most web servers redirect the client to a URI with the slash added, so that relative links work correctly.

Canonicalizing directory names

• 클라이언트가 뒤따라오는 슬래시 없이 디렉토리 이름에 대한 URI를 요청할 때, 대부분의 웹 서버는 Relative 링크가 잘 작동하도록 슬래시를 추가한 URI로 클라이언트를 리디렉트합니다.

---

Step 6: Sending Responses

Web servers face similar issues sending data across connections as they do receiving. The server may have many connections to many clients, some idle, some sending data to the server, and some carrying response data back to the clients.

• 웹 서버는 수신할 때와 마찬가지로 연결을 통해 데이터를 송신할 때 비슷한 문제에 직면합니다.

• 서버는 클라이언트와 많은 연결을 가지고 있을지도 모릅니다. 그 중 일부는 유휴 연결이고, 클라이언트가 서버에 데이터를 전송 중이며, 클라이언트에게 응답 데이터를 전송하는 중일 수 있습니다.

The server needs to keep track of the connection state and handle persistent connections with special care. For nonpersistent connections, the server is expected to close its side of the connection when the entire message is sent.

• 서버는 연결의 상태를 추적하고 Persistent 연결을 심혈을 기울여 처리해야 합니다.

• Persistent가 아닌 연결에 대해 서버는 전체 메시지가 수신되었을 때 연결을 종료할 것이라고 예측합니다.

For persistent connections, the connection may stay open, in which case the server needs to be extra cautious to compute the Content-Length header correctly, or the client will have no way of knowing when a response ends (see Chapter 4).

• Persistent 연결의 경우, 연결이 지속될 것입니다.

• 이 경우 서버는 Content-Length 헤더를 올바르게 해석하기 위해 각별히 주의해야 합니다. 그렇지 않으면 클라이언트는 응답이 종료되는 시점을 알 수 없습니다. (Chapter 4)

---

Step 7: Logging

Finally, when a transaction is complete, the web server notes an entry into a log file, describing the transaction performed. Most web servers provide several configurable forms of logging. Refer to Chapter 21 for more details.

• 마지막으로, 트랜잭션이 완료되었을 때 웹 서버는 로그 파일에 수행된 트랜잭션을 나타내는 입력을 기록합니다.

• 대부분의 웹 서버는 로깅의 몇 가지 구성 가능한 형태를 제공합니다.

• 자세한 내용은 Chapter 21을 참고하기 바랍니다.

---

🧡 요약 정리 🧡

Step 1: Accepting Client Connections
Step 2: Receiving Request Messages
Step 3: Processing Requests
Step 4: Mapping and Accessing Resources

Step 5: Building Responses

• 웹 서버가 요청 메소드에 나타난 액션을 수행하여 응답을 반환하는 과정
• 응답 메시지는 Content-Type, Content-Length, Body Contents 포함

MIME Typing

• 파일명 확장자 사용
• Magic Typing : Magic File에 콘텐츠를 매칭하여 MIME 타입 결정
• Explicit Typing : 확장자나 콘텐츠에 관계없이 강제 타입 결정
• Type Negotiation : 사용자와의 협상 과정을 거쳐 타입 결정

Redirection

• Permanently Moved Resources : (301) 다음 요청에도 클라이언트가 변경된 리소스로 접근하고 북마크를 업데이트할 수 있게 하는 것
• Temporarily Moved Resources : (303, 307) 클라이언트가 다음부터 원래의 URL로 접속하고 북마크를 업데이트하지 않게 하는 것
• URL Augmentation : (303, 307) 트랜잭션 과정에서 상태 정보를 유지하기 위해 임베딩된 상태 정보를 포함하는 새로운 URL을 생성해 리디렉션하는 것
• Load Balancing : (303, 307) 과부하가 걸리지 않은 서버로 클라이언트를 리디렉션하는 것
• Server Affinity : (303, 307) 클라이언트에 대한 정보를 포함하고 있는 서버로 클라이언트를 리디렉션하는 것
• Canonicalizing directory names : 후행 슬래시가 없는 URI에 대해 슬래시를 추가하여 클라이언트를 리디렉션하는 것

Step 6: Sending Responses

• 서버는 연결의 상태를 추적하고 Persistent 연결에 각별히 주의해야 한다
• Chapter 4 내용 참고

Step 7: Logging

• 웹 서버가 수행된 트랜잭션에 대한 로그 기록
• Chapter 21 참고

---

💛 감상 💛

• 오늘 내용을 공부하면서 리디렉션 상태 코드에 관한 부분을 다시 한 번 살펴보았습니다. 읽은지 얼마나 됐다고 그새 또 까먹어서 당황스러웠습니다.

• 분량 조절을 잘못해서 오늘 그냥 Chapter 5를 끝내버렸습니다. 다음 포스팅부터는 프록시에 대해 작성하겠습니다.

• 오늘도 감상을 쓸 시간이 없습니다. 다른 일을 하러 가보겠습니다....