3.1.5.2 Receiving a Response (All Request Types)

  • Article

This section specifies common steps that MUST be performed whenever the client receives the response to a request that it has sent. These steps MUST be performed prior to any processing that is specific to a particular request type.

The client MUST assume that the responses are received in exactly the same order in which the requests are sent.

The client MUST check the status code in the response to determine if the request succeeded, as specified in [RFC2326] section 11. The sections dealing with responses for specific request types can have rules for how to handle failed requests, and any such rules MUST be followed. However, if the status code indicates that the request failed, and if the response is for a Describe, Play, or SelectStream request, and no other rules describe how to handle the failure, then this MUST be treated as an error and reported as such to the higher layer. If the response is not for a Describe, Play, or SelectStream request, then responses that indicate a failure SHOULD be processed the same way as if they indicated a success.

The client MUST process the Supported header, if present <24>. Each feature token on the header MUST be added to the Server-features variable in the abstract data model. If the header is present, any feature token not listed on the header MUST be removed from the Server-features variable.

The client MUST process the X-Playlist-Gen-Id (section 2.2.6.22) header, if present. If it is present, the Playlist-gen-id variable in the abstract data model MUST be set to the numerical value specified on that header.

The client MUST process the timeout parameter on the Session header, if present. If the Session header is present, the KeepAlive-timeout variable in the abstract data model MUST be set to the value of the delta-seconds syntax element. If the timeout parameter is missing, the KeepAlive-timeout variable MUST be set to the default value for the delta-seconds syntax element. The Session header is specified in [RFC2326] section 12.37.

The client SHOULD adhere to the directives specified by the Cache-Control (section 2.2.6.2) header and MUST NOT cache the content unless explicitly allowed by the appropriate directive (that is, must-revalidate, public, or proxy-revalidate).

If the Set-Cookie header is present in the response, the cookies on that header MUST be processed according to the rules specified in section 2.2.6.9.