3.1.5.1 Receiving a PushSetup Response

The client MUST verify that the response adheres to the syntax specified in section 2.2.2.1.

If the HTTP status code in the response is in the range 300 through 305, the server is requesting the client to connect to another server. The client MUST connect to the server specified in the response, by following the rules as specified in [RFC2616] section 10.3. A brief summary of the rules is, if the status code is 305, the URL on the Location header (as specified in [RFC2616] section 14.30) is for a proxy, and the URL that is used in the PushSetup request MUST remain unchanged. For status codes 300 through 304, the URL on the Location header MUST replace the URL used in the PushSetup request. The client MUST close the current TCP connection and establish a new TCP connection to the server or proxy server, as appropriate, depending on the status code. If a proxy server is used, the value of the UsingProxy flag in the abstract data model MUST be set to one. Otherwise, it MUST be set to zero. The client MUST then continue by following the steps specified in section 3.1.4.1.1.

If the HTTP status code in the response is 401, the server requires access authentication. Status code 407 means that a proxy server requires access authentication. The rules for access authentication, as specified in [RFC2616] section 11, MUST be followed. When the client is ready to resubmit the HTTP request with the authentication credentials that the server requested, the client MUST establish a new TCP connection to the server and send the HTTP request on that connection. When resubmitting the request, the client MUST follow the steps specified in section 3.1.4.1.1.<4>

Otherwise, if the HTTP status code indicates that the request succeeded, the client MUST perform the following steps:

  1. The client MUST inspect the Server (section 2.2.1.5) header in the response. If the Server header is missing or if the server-token parameter on the Server header does not match any of the values used by this protocol (as specified in [MS-WMSP] section 2.2.1.5), the server is not compatible with the Windows Media HTTP Push Distribution Protocol and is probably a regular HTTP web server. Because this protocol does not interoperate with incompatible servers, this incompatibility MUST be treated as an error and reported as such to the higher layer.

  2. If the Set-Cookie (section 2.2.1.6) header is present in the response, the value of the Push-ID variable in the abstract data model MUST be set to the value of the push-id cookie. Any other cookies that are specified SHOULD be saved for inclusion in the Cookie header in subsequent requests.

  3. If the Via header (as specified in [RFC2616] section 14.45) is present in the response, the value of the UsingProxy flag in the abstract data model MUST be set to one.

    Note Proxy servers that only support HTTP 1.0 are not likely to send the Via header.

  4. The client SHOULD keep the TCP connection to the server open, so that it can be used for sending the PushStart request.

  5. The client MUST inform the higher layer that the PushSetup request succeeded and that it is now possible to start streaming data to the server. The client MUST wait for a higher-layer triggered event.