Chapter 6. Proxies
(해석 또는 이해가 잘못된 부분이 있다면 댓글로 편하게 알려주세요.)
❤️ 원문 번역 ❤️
Proxy Interoperation
Clients, servers, and proxies are built by multiple vendors, to different versions of the HTTP specification. They support various features and have different bugs. Proxy servers need to intermediate between client-side and server-side devices, which may implement different protocols and have troublesome quirks.
-
클라이언트, 서버, 프록시는 다수의 제공업자에 의해 서로 다른 HTTP 명세 버전으로 만들어집니다.
-
서로 다른 버전은 서로 다른 특징과 버그를 가지고 있습니다.
-
프록시 서버는 서로 다른 프로토콜을 구현하여 여러 번거로운 문제가 있는 클라이언트 사이드 디바이스와 서버 사이드 디바이스 사이를 중개할 필요가 있습니다.
Handling Unsupported Headers and Methods
The proxy server may not understand all the header fields that pass through it. Some headers may be newer than the proxy itself; others may be customized header fields unique to a particular application. Proxies must forward unrecognized header fields and must maintain the relative order of header fields with the same name.* Similarly, if a proxy is unfamiliar with a method, it should try to forward the message to the next hop, if possible.
-
프록시 서버가 프록시를 통과하는 모든 헤더 필드를 이해하고 있지는 않을 것입니다.
-
일부 헤더는 프록시 버전보다 더 최신일 수도 있고, 특정 애플리케이션의 고유한 사용자 정의 헤더 필드일지도 모릅니다.
-
프록시는 인식하지 못한 헤더를 반드시 포워딩해야 하고, 동일한 이름을 가진 헤더 필드의 상대적인 순서를 유지해야 합니다.
-
마찬가지로 프록시가 메소드에 익숙하지 않다면 메시지를 가능한 한 다음 홉으로 포워딩하기 위해 노력해야 합니다.
Proxies that cannot tunnel unsupported methods may not be viable in most networks today, because Hotmail access through Microsoft Outlook makes extensive use of HTTP extension methods.
- 지원되지 않는 메소드를 연결할 수 없는 프록시는 오늘날 대부분의 네트워크에서 사용할 수 없습니다. Microsoft Outlook을 통한 Hotmail 접근은 HTTP 확장 메소드를 광범위하게 사용하기 때문입니다.
OPTIONS: Discovering Optional Feature Support
The HTTP OPTIONS method lets a client (or proxy) discover the supported functionality (for example, supported methods) of a web server or of a particular resource on a web server (Figure 6-26). Clients can use OPTIONS to determine a server’s capabilities before interacting with the server, making it easier to interoperate with proxies and servers of different feature levels.
-
클라이언트나 프록시는 HTTP의 OPTION 메소드를 통해 웹 서버 또는 웹 서버에 위치한 특정 리소스에 대해 지원되는 기능을 검색합니다. (Figure 6-26)
-
클라이언트는 서버와 상호작용하기 전 서버의 능력을 결정하기 위해 OPTIONS를 사용할 수 있습니다. 이것은 서로 다른 기능 단계를 가진 프록시 및 서버와의 상호 운용을 편리하게 합니다.
If the URI of the OPTIONS request is an asterisk (*), the request pertains to the entire server’s supported functionality. For example:
OPTIONS * HTTP/1.1
- 만약 OPTIONS 요청의 URI가 asterisk(*)라면, 요청은 전체 서버의 지원되는 기능과 관련이 있습니다.
If the URI is a real resource, the OPTIONS request inquires about the features available to that particular resource:
OPTIONS http://www.joes-hardware.com/index.html HTTP/1.1
- 만약 URI가 실제 리소스라면, OPTIONS 요청은 특정한 리소스에 대해 사용 가능한 기능을 문의합니다.
On success, the OPTIONS method returns a 200 OK response that includes various header fields that describe optional features that are supported on the server or available to the resource. The only header field that HTTP/1.1 specifies in the response is the Allow header, which describes what methods are supported by the server (or particular resource on the server).* OPTIONS allows an optional response body with more information, but this is undefined.
-
성공하는 경우 OPTIONS 메소드는 200 OK 응답을 반환합니다. 응답에는 서버에서 지원되거나 리소스에 대해 이용할 수 있는 선택적인 기능을 나타내는 여러 헤더 필드가 포함됩니다.
-
HTTP/1.1를 응답으로 특정화하는 헤더 필드는 Allow 헤더입니다. 이 헤더는 서버(혹은 서버의 특정 리소스)에 의해 지원되는 메소드가 무엇인지를 나타냅니다.
-
OPTIONS는 추가 정보를 포함하는 선택적인 응답 본문을 허용하지만 정의되어 있지 않습니다.
The Allow Header
The Allow entity header field lists the set of methods supported by the resource identified by the request URI, or the entire server if the request URI is *. For example:
Allow: GET, HEAD, PUT
-
Allow 본문 헤더 필드는 요청 URI로 식별되는 리소스에 의해 지원되는 메소드의 집합을 나열합니다. 만약 요청 URI가 *라면 전체 서버에 의해 지원되는 메소드 집합을 나열합니다.
Allow: GET, HEAD, PUT
The Allow header can be used as a request header to recommend the methods to be supported by the new resource. The server is not required to support these methods and should include an Allow header in the matching response, listing the actual supported methods.
-
Allow 헤더는 새로운 리소스에 의해 지원되는 메소드를 추천하기 위해 요청 헤더로 사용할 수 있습니다.
-
서버는 해당 메소드를 지원할 필요가 없고, 응답을 매칭하는 과정에서 실제로 지원되는 메소드를 나열한 Allow 헤더를 포함해야 합니다.
A proxy can’t modify the Allow header field even if it does not understand all the methods specified, because the client might have other paths to talk to the origin server.
- 프록시가 지정된 모든 메소드를 이해하지 못한다고 하더라도, 프록시는 Allow 헤더 필드를 수정할 수 없습니다. 클라이언트가 origin 서버와 통신하는 다른 경로를 가지고 있을지도 모르기 때문입니다.
🧡 요약 정리 🧡
Proxy Interoperation
: 서로 다른 프로토콜 버전으로 구현된 서버 사이드와 클라이언트 사이드 중개
- 프록시는 자신이 인식하지 못한 헤더도 포워딩해야 한다
- 프록시는 Allow 헤더 필드를 수정할 수 없다
OPTIONS
- 웹 서버, 혹은 웹 서버의 특정 리소스에 대해 지원되는 기능을 검색하는 메소드
- 요청 URI가 asterisk(*) : 전체 서버의 지원 기능
- 요청 URI가 실제 리소스 : 리소스에 대해 지원되는 기능
- 요청에 성공하면 200 OK와 함께 Allow 헤더에 기능 목록 반환
Allow: GET, HEAD, PUT
💛 감상 💛
-
시험 기간 한복판에 업로드하려니 보통 일이 아니군요... 바쁜 일이 끝나는대로 다시 제대로 복귀하겠습니다! ㅜㅜ
-
오늘로 Proxy 파트가 종료됩니다. 다음 포스팅부터는 Caching에 대해 공부하도록 하겠습니다.
