Chapter 3. HTTP Messages
(해석 또는 이해가 잘못된 부분이 있다면 댓글로 편하게 알려주세요.)
❤️ 원문 번역 ❤️
Methods
Let’s talk in more detail about some of the basic HTTP methods, listed earlier in Table 3-1.
-
Table 3-1에 나왔던 몇 가지 HTTP 메소드에 대해 더 자세히 이야기해봅시다.
** [1] GET과 [2] HEAD는 지난 포스팅을 참고해주시기 바랍니다.
[3] PUT
The PUT method writes documents to a server, in the inverse of the way that GET reads documents from a server. Some publishing systems let you create web pages and install them directly on a web server using PUT (see Figure 3-9).
-
PUT 메소드는 서버로부터 문서를 불러오는 GET 메소드와 반대로 서버에 문서를 작성하는 메소드입니다.
-
일부 게시 시스템에서는 PUT을 활용하여 웹 페이지를 생성하고 웹 서버에 직접 설치하도록 합니다. (Figure 3-9)
The semantics of the PUT method are for the server to take the body of the request and either use it to create a new document named by the requested URL or, if that URL already exists, use the body to replace it.
- PUT 메소드의 의미는 서버가 요청의 본문을 취하여 요청 URL로 명명된 새로운 문서를 생성하거나, URL이 이미 존재한다면 문서를 대체하는 데 본문을 활용하는 것입니다.
Because PUT allows you to change content, many web servers require you to log in with a password before you can perform a PUT. You can read more about password authentication in Chapter 12.
-
PUT은 콘텐츠를 변화시킬 수 있으므로 많은 웹 서버가 PUT 메소드를 수행하기 전 패스워드를 사용한 로그인을 필요로 합니다.
-
패스워드 인증에 대해서는 Chapter 12에서 자세히 다룹니다.
ㅤ
[4] POST
The POST method was designed to send input data to the server.* In practice, it is often used to support HTML forms. The data from a filled-in form typically is sent to the server, which then marshals it off to where it needs to go (e.g., to a server gateway program, which then processes it). Figure 3-10 shows a client making an HTTP request—sending form data to a server—with the POST method.
-
POST 메소드는 입력 데이터를 서버에 전달하기 위해 설계되었습니다.
* 실전에서는 보통 HTML 형태를 지원하는 데 사용됩니다. -
전형적인 방식으로 채워진 데이터는 서버에 전달되어 데이터가 필요한 곳에 집결됩니다. (ex. 데이터를 처리하는 서버 게이트웨이 프로그램)
-
Figure 3-10은 POST 메소드를 사용하여 서버로 정형화된 데이터를 전송하는 클라이언트의 HTTP 요청을 보여줍니다.
[5] TRACE
When a client makes a request, that request may have to travel through firewalls, proxies, gateways, or other applications. Each of these has the opportunity to modify the original HTTP request. The TRACE method allows clients to see how its request looks when it finally makes it to the server.
-
클라이언트가 생성한 요청은 방화벽이나 프록시, 게이트웨이, 혹은 그 밖의 응용 프로그램을 통과할 수도 있습니다.
-
각각의 요소들은 원본의 HTTP 요청을 바꿀 가능성이 있습니다.
-
TRACE 메소드는 요청이 서버에 최종적으로 도착했을 때 어떻게 생겼는지를 클라이언트가 알 수 있게 합니다.
A TRACE request initiates a “loopback” diagnostic at the destination server. The server at the final leg of the trip bounces back a TRACE response, with the virgin request message it received in the body of its response. A client can then see how, or if, its original message was munged or modified along the request/response chain of any intervening HTTP applications (see Figure 3-11).
-
TRACE는 대상 서버에서 "루프백" 진단을 시작합니다.
-
여행의 마지막 목적지인 서버는 자신이 받은 요청 메시지를 응답의 본문에 넣어 TRACE 응답을 되돌려줍니다.
-
클라이언트는 원본 메시지가 간섭중인 모든 HTTP 애플리케이션의 요청/응답 체인에서 어떻게 처리되고 수정되었는지 확인할 수 있습니다. (Figure 3-11)
The TRACE method is used primarily for diagnostics; i.e., verifying that requests are going through the request/response chain as intended. It’s also a good tool for seeing the effects of proxies and other applications on your requests.
-
TRACE 메소드는 진단에 주로 이용됩니다. 예를 들면 요청이 의도한대로 요청/응답 체인을 통과하는지를 확인하는 것이 있습니다.
-
그리고 이것은 요청이 통과하는 프록시나 다른 애플리케이션의 효과를 알아보는 데에도 좋은 도구가 됩니다.
As good as TRACE is for diagnostics, it does have the drawback of assuming that intervening applications will treat different types of requests (different methods— GET, HEAD, POST, etc.) the same. Many HTTP applications do different things depending on the method—for example, a proxy might pass a POST request directly to the server but attempt to send a GET request to another HTTP application (such as a web cache). TRACE does not provide a mechanism to distinguish methods. Generally, intervening applications make the call as to how they process a TRACE request.
-
TRACE가 진단에 훌륭한 만큼, 요청에 간섭하는 애플리케이션이 서로 다른 유형의 요청(GET, HEAD, POST 등의 서로 다른 메소드)을 똑같이 처리할 것이라고 가정한다는 단점도 분명 있습니다.
-
많은 HTTP 애플리케이션이 메소드에 따라 다른 작업을 수행하고 있습니다. 예를 들어, 프록시는 POST 요청을 직접 서버로 전달하지만 다른 HTTP 애플리케이션(웹 캐시 등)에 GET 요청을 보내려고 시도할 수 있습니다.
-
TRACE는 메소드를 구별하는 매커니즘을 제공하지 않습니다.
-
일반적으로 요청에 간섭하는 애플리케이션은 TRACE 요청을 처리하는 방식에 대한 호출을 생성합니다.
No entity body can be sent with a TRACE request. The entity body of the TRACE response contains, verbatim, the request that the responding server received.
-
TRACE 요청에 함께 보낼 수 있는 엔티티 본문은 없습니다.
-
TRACE 응답의 엔티티 본문은 응답하는 서버가 수신한 요청을 포함합니다.
🧡 요약 정리🧡
Methods
[3] PUT
- 서버에 문서를 작성하는 메소드
- 요청 URL로 명명된 새로운 리소스 생성 or 이미 존재하는 리소스 대체
[4] POST
- 입력 데이터를 서버에 전달하는 메소드(서버 게이트웨이 프로그램 등에 이용)
- 일반적으로 HTML 형태를 지원하는 데 사용
[5] TRACE
- 대상 서버에 도착한 요청의 형태를 알려주는 진단 메소드
- (1) 요청이 의도한대로 요청/응답 체인을 통과하는지 확인
- (2) 방화벽, 프록시, 게이트웨이 등이 제대로 작동하는지 확인 - 요청 메시지 : 엔티티 본문을 포함할 수 없음
- 응답 메시지 : 엔티티 본문에 서버가 받은 요청 포함
- 한계 : 메소드를 구별하는 매커니즘을 제공하지 않음
💛 감상 💛
-
TRACE 메소드는 있는 줄도 몰랐다. 지금까지는 기본적인 GET, HEAD, PUT, POST, DELETE 정도만 알고 있었다. 생각해보면 TRACE 메소드는 오늘날 반드시 필요할 수밖에 없을 것 같다. 웹에는 프록시 서버도 존재하고 방화벽도 존재하는데 요청 메시지가 변화할 가능성을 항상 염두에 두어야 하지 않겠는가. 무언가 요청이 뜻대로 되지 않았을 때 이를 추적할 수 있는 수단을 내가 알고 있다면 분명 도움이 될 것이다.
-
이 책은 그림이 이해하기 쉽게 잘 나와있어서 좋다. 오늘도 TRACE 파트를 읽으면서 잘 이해가 안 되는 부분도 많았는데 그림이 속 시원하게 해결해주었다. 그렇지만 그 전에 영어 독해 실력부터 좀 더 키워야겠다...ㅠㅠ
