3.2 Example 2: Reading a File Using HTTP as the Metadata Channel in Hosted Cache Mode
This example includes the following use cases: Configure HTTP Content Server Caching (section 2.5.4.1.2), Configure a Hosted Cache Server (section 2.5.4.1.4), Configure Content Client Caching Mode (section 2.5.4.1.3), HTTP Metadata Retrieval (section 2.5.4.3.2), Content Discovery and Retrieval (cached data unavailable) (section 2.5.4.4.1), and Content Discovery and Retrieval with Hosted Cache (Cached Data Available) (section 2.5.4.4.2).
In this example, the HTTP protocol plays two distinct roles. The first role is to act in the usual manner as a file retrieval protocol. The second role is through the use of PeerDist, as described in [MS-PCCRTP], to act as a transport for metadata from a content server to a content client, which allows the content client to participate in the initial stages of Content Caching and Retrieval.
The message sequence steps for this example are organized into the following sections:
Peer1:
A. Metadata retrieval over HTTP.
B. Content discovery in hosted cache mode (content unavailable).
C. Return trip to the content server for content download.
D. Content client offers the content to the hosted cache server.
E. Hosted cache server downloads the content from the content client.
Peer2:
F. Metadata retrieval over HTTP.
G. Content discovery and download from the hosted cache server (content available).
As shown in the preceding list, Peer1 is the content client for messages of sections A, B, C, D, and E, whereas Peer2 is the content client for messages of sections F and G.
Initial System State and Prerequisites
The Content Caching and Retrieval is enabled on the content server as described in the Configure HTTP Content Server caching (section 2.5.4.1.2) use case.
The hosted cache server is configured with the required X.509 certificate to enable the server authentication with secure SSL/TLS.
The mode of content caching as "hosted cache" is configured on the server as described in the Configuring a Hosted Cache Server (section 2.5.4.1.4) use case.
The content to be requested is not available on the hosted cache server but is available on the content server.
The hosted cache server is configured to require client authentication.
The mode of content caching as "hosted client" is configured on the content clients (for example, Peer1 and Peer 2), as described in the Configure Content Client Caching Mode (section 2.5.4.1.3) use case.
The content clients (for example, Peer1 and Peer2) are configured with the FQDN of the hosted cache server.
On both content clients (Peer1 and Peer2), the use of Internet Explorer initiates the content transfer.

Figure 11: Content retrieval and offering (Peer1)
-
A. HTTP metadata retrieval
The content client (Peer1) sends an HTTP GET request to the content server. The content client indicates in the HTTP request header that it is PeerDist-enabled by listing PeerDist as an accepted encoding. It also declares the version of PeerDist encoding, for example, X-P2P-PeerDist: Version=1.0, as described in [MS-PCCRTP] section 3.1.4.
In the HTTP 200 (OK) response, the content server indicates that the content is encoded by using the PeerDist content encoding. It also includes the content length and indicates the length of the metadata. The metadata is constructed as described in [MS-PCCRTP] section 3.2.5.1.
B. Content discovery in hosted cache mode (content unavailable)
The content client (Peer1) initiates the transport with the hosted cache server by sending an HTTP POST request to the root path of {/116B50EB-ECE2-41ac-8429-9F9E963361B7/} of the server. That request also carries a REQUEST-MESSAGE (MSG_GETBLKS) message, as described in [MS-PCCRR] section 2.2.4.3, that is carried as an entity body of the HTTP POST request to the hosted cache server and requests content of block index Zero within the target segment that the content client is querying.
The hosted cache server responds with an HTTP status code of 200 (OK) for the URL /116B50EB-ECE2-41ac-8429-9F9E963361B7/ and RESPONSE-MESSAGE (MSG_BLK), as described in [MS-PCCRR] section 2.2.5.3, which indicates that content is not available for download from the hosted cache server.
C. Return trip to the content server for content download
The content client (Peer1) downloads the requested content from the content server by using HTTP protocol.
The content client (Peer1) sends an HTTP GET request to the content server to download the content.
The content server responds with an HTTP status code of 200 (OK) and also the requested content.
D. Content client offers the content to the hosted cache server
The initial SSL handshake is not discussed; only the traffic that is pertinent to Content Caching and Retrieval is shown. The URL on which the hosted cache server listens is normally https://:<port number>/C574AC30-5794-4AEE-B1BB-6651C5315029/. The port number is configurable but would normally be 443 for HTTPS. If the hosted cache server is configured to something other than port 443, content clients also have to be configured to use that port.
The content client (Peer1) sends a request message as the payload of an HTTP POST request to the hosted cache server. The message is a PCHC initial offer of content to the hosted cache; see message 7 (as described in [MS-PCHC] section 2.2.1.3) in the figure in this section.
The hosted cache server responds with an HTTP 401 (Unauthorized) message. The HTTP response is as follows.
Http: Response, HTTP/1.1, Status: Unauthorized, URL: /C574AC30-5794-4AEE-B1BB-6651C5315029/, Using Negotiate Date: Authentication ProtocolVersion: HTTP/1.1 StatusCode: 401, Unauthorized Reason: NotAuthenticated + ContentType: text/html Server: Microsoft-HTTPAPI/2.0 - WWWAuthenticate: Negotiate
The content client (Peer1) and hosted cache server use the mechanisms as described in [RFC4559], which are based on GSS-API [RFC2743]. The exact number of packets that are exchanged during client authentication depends on the authentication mechanism<19> and whether the authentication is successful. In any case, if authentication fails for any reason, the content client (Peer1) cannot offer content to the hosted cache server. In this example, a successful case of client authentication with Kerberos [MS-KILE] as the authentication mechanism is covered.
The content client (Peer1), on receipt of the HTTP 401 (Unauthorized) response, is expected to repeat the previous POST message that passes an HTTP Authorization header line. In this example, the content client passes the GSS-API SPNEGO token that contains the Kerberos token as the optimistic token in the Authorization header. For information on SPNEGO see [MS-SPNG] and [MS-NEGOEX].
The hosted cache server verifies the Authorization header, which is received in the previous step, and authenticates the content client (Peer1). After authentication, message processing proceeds as the PCHC initial offer of content is made to the hosted cache server, which then responds with a response code of 1 (see [MS-PCHC] section 2.2.2.2) that indicates that it will accept block hashes.
The content client responds by sending a SEGMENT_INFO_MESSAGE message as described in [MS-PCHC] section 2.2.1.4. This message contains the segment hash of data (HoD) for the previously offered segment and the range of block hashes in the segment.
After the hosted cache server obtains the SEGMENT_INFO_MESSAGE message, it responds with an HTTP 200 (OK) response.
E. Hosted cache server downloads the content from content client
The hosted cache server initiates the transport with the content client (Peer1) by sending an HTTP POST request to the root path of {/116B50EB-ECE2-41ac-8429-9F9E963361B7/} of the server. That request also carries a REQUEST-MESSAGE (MSG_GETBLKLIST), as described in [MS-PCCRR] section 2.2.4.2, that is carried as an entity body of the HTTP POST request to the content client requesting the block IDs of the blocks within the target segment that the hosted cache server is querying.
The content client (Peer1) responds with an HTTP status code of 200 (OK) for the URL /116B50EB-ECE2-41ac-8429-9F9E963361B7/ and a RESPONSE-MESSAGE (MSG_BLKLIST), as described in [MS-PCCRR] section 2.2.5.2, that indicates the blocks that are currently available for download from the content client (Peer1).
The hosted cache server sends a REQUEST-MESSAGE (MSG_GETBLKS), as described in [MS-PCCRR] section 2.2.4.3, to the content client (Peer1).
The content client (Peer1) responds with RESPONSE-MESSAGE (MSG_BLK) as described in [MS-PCCRR] section 2.2.5.3.
Steps 13 and 14 followed by 15 and 16 are repeated until the required content is transferred.
Peer2:

Figure 12: Content Retrieval (Peer2)
F. Metadata retrieval over HTTP
The content client (Peer2) sends an HTTP GET request to the content server. The content client indicates in the HTTP request header that it is PeerDist-enabled by listing PeerDist as an accepted encoding, as described in [MS-PCCRTP] section 3.1.4.
In the HTTP 200 (OK) response, the content server indicates that the content is encoded by using the PeerDist content encoding. It also includes the content length and indicates the length of the metadata. The metadata is constructed as described in [MS-PCCRTP] section 3.2.5.1.
G. Content discovery and download from hosted cache mode (content available)
The content client (Peer2) initiates the transport with the hosted cache server by sending an HTTP POST request to the root path of {/116B50EB-ECE2-41ac-8429-9F9E963361B7/} of the server. That request also carries a REQUEST-MESSAGE (MSG_GETBLKS), as described in [MS-PCCRR] section 2.2.4.3, that is carried as an entity body of the HTTP POST request to the hosted cache server requesting content for a specific block (starting from index 0) within the target segment that the content client is querying.
The hosted cache server responds with an HTTP status code of 200 (OK) for the URL /116B50EB-ECE2-41ac-8429-9F9E963361B7/ and a RESPONSE-MESSAGE (MSG_BLK) as described in [MS-PCCRR] section 2.2.5.3, with the content of the requested block index.
Steps 19 and 20 are repeated until the required content is transferred.
Final System State
Content clients (for example, Peer1 and Peer2) retrieved the requested content.
The cached content is available on the hosted cache server.