3.3.5.2 Tunnel and Channel Creation
From this phase forward, all packets exchange is done in the HTTP entity body.
Packets from the RDG client to the RDG server are sent as the request entity body of the IN channel. These packets are sent as self-delimiting chunks. Packets from the RDG server to the RDG client are sent as the response entity body of the OUT channel. The packet formats are defined in section 2.2.10.
The first set of messages exchanged is the version negotiation packet HTTP_HANDSHAKE_REQUEST_PACKET (section 2.2.10.10) (shown in steps 8 and 9 in the figure in section 3.3.5.1). The version field in this packet indicates the highest protocol version supported by the RDG client. If the RDG server does not support the specified version, the connection is dropped. If the RDG server receives a version number lower than what it supports, it MAY respond back with that same version number. That is, the RDG server is now operating in a lower version mode. It MAY drop the connection with an error message if it does not support the RDG client's version. If the RDG server receives a higher version number than it supports, it responds with an error message packet. The same applies to the RDG client logic.
The RDG client sends an HTTP_TUNNEL_PACKET and receives a corresponding HTTP_TUNNEL_RESPONSE (shown in steps 10 and 11 in the figure in section 3.3.5.1). If the response contains an error, the client closes the connection and sends the error to the higher layer. At the end of this step, the RDG client has passed CAP (Connection Authorization Policies) checks.
The RDG client MUST send the HTTP_TUNNEL_AUTH_PACKET, appending HTTP_TUNNEL_AUTH_PACKET_OPTIONAL, to the RDG server (shown in step 11 in the figure in section 3.3.5.1). The client MUST set clientName as the name of the RDG client, cbClientName as the length of the RDG client name, fieldsPresent as HTTP_TUNNEL_AUTH_FIELD_SOH (if Negotiated Capabilities contains HTTP_CAPABILITY_TYPE_QUAR_SOH), and statementOfHealth and clientName of the HTTP_TUNNEL_AUTH_PACKET_OPTIONAL structure to authorize the tunnel.
The RDG client MUST receive the HTTP_TUNNEL_AUTH_RESPONSE and HTTP_TUNNEL_AUTH_RESPONSE_OPTIONAL structures (shown in step 12 in the figure in section 3.3.5.1). If the errorCode in HTTP_TUNNEL_AUTH_RESPONSE is S_OK or E_PROXY_QUARANTINE_ACCESSDENIED, continue the following steps. Otherwise, the RDG client MUST close the connection.
The RDG client sends an HTTP_CHANNEL_PACKET with the target server details and receives a corresponding response (shown in steps 12 and 13 in the figure in section 3.3.5.1). If the response contains an error, the RDG client MAY close the connection. At the end of this step, the RDG client has passed RAP (Resource Authorization Policies) checks and is successfully connected to the target server.

Figure 18: Data flow and connection close