2.1.2.1 Client to Inbound or Outbound Proxy

  • Article

RPC over HTTP v2 MUST operate either on top of HTTP or on top of HTTPS. It requires HTTP 1.0 plus connection keep-alive support from HTTP 1.1. Mapping to both protocols happens identically. In this section, mapping is defined only on HTTP, but the same rules apply for HTTPS.<5>

If instructed by a higher-level protocol in an implementation-specific way, implementations of this protocol MUST require the HTTP implementation on the client to authenticate to the HTTP server running on the inbound proxy or outbound proxy using basic authentication for HTTP [RFC2617] or NTLM authentication for HTTP [MS-NTHT].

The higher-level protocol MUST provide, in an implementation-specific way, either credentials in the form of user name/password or a client-side certificate. Implementations of this protocol MUST NOT process the credentials or authentication information. Such processing typically happens entirely inside implementations of lower protocol layers.<6>

The same mapping MUST be applied for both the inbound proxy and the outbound proxy traffic. A client implementation SHOULD instruct the implementation of the HTTP protocol on which it runs to use an implementation-specific but reasonable time-out value for all requests.<7>

RPC over HTTP v2 MUST always use a pair of HTTP requests to build a virtual connection (2). The HTTP requests MUST be initiated by the client and received by the inbound proxy and outbound proxy.

Both HTTP requests have implementation-specific content length as defined in the following sections. The address of the HTTP server is provided by a higher-layer protocol. RPC over HTTP v2 always uses port 80 for HTTP traffic and port 443 for HTTPS traffic.

The next few sections describe the HTTP IN channel request (section 2.1.2.1.1) and OUT channel request (section 2.1.2.1.2), and the IN channel response (section 2.1.2.1.3) and OUT channel response (section 2.1.2.1.4) used by RPC over HTTP v2 as well as the mapping of the PDU stream on top of these requests. The general syntax and meaning of each of the HTTP header fields are specified in [RFC2616]. Sections 2.1.2.1.1 through 2.1.2.1.8 only define the use of a given header field when this protocol uses the field in a more specific or different meaning than the one specified in [RFC2616]. RPC over HTTP v2 protocol entirely preserves the syntax and semantics of any HTTP header field not explicitly mentioned here.