RFC2326(中文版)(17)

RFC2326(中文版)

2.28
| Retry-After ; Section 12.31
| Server ; Section 12.36
| Vary ; Section 12.42
| WWW-Authenticate ; Section 12.44

回应标题域名只有在与协议版本的变化结合起来后，才能进行可靠的扩展。实际上，新
的或实验中的标题域只要能被通讯各方识别，其语法就可使用，而无法识别的标题域都将被
视为实体域。

8 实体
如不受请求方法或回应状态编码限制，请求和回应消息可传输实体，实体由实体标题域和实体主体组成，有些回应仅包括实体头。
在此，根据谁发送实体、谁接收实体，发送者和接收者可分别指用户和服务器。
8.1 实体标题域
实体标题定义实体主体可选元信息，如没有实体主体，指请求标识的资源。

entity-header = Allow ; Section 12.4
| Content-Base ; Section 12.11
| Content-Encoding ; Section 12.12
| Content-Language ; Section 12.13
| Content-Length ; Section 12.14
| Content-Location ; Section 12.15
| Content-Type ; Section 12.16
| Expires ; Section 12.19
| Last-Modified ; Section 12.24
| extension-header
extension-header = message-header

扩展头机制允许定义附加实体标题域，而不用改变协议，但这些段不能假定接收者能识别。不可识别标题域应被接收者忽略，而让代理转发。
8.2 实体主体
见[H7.2]
　 与RTSP请求或回应一起发送的实体主体的格式和编码信息都在实体标题域
（Entity-Header）中定义。

Entity-Body = *OCTET

实体主体只在请求方法有要求时才会被放在请求消息中。请求消息标题域处的内容长度
标题域（Content-Length header field）的标志将指明请求中的实体主体是否存在。包含实体
主体的RTSP/1.0请求必须包含合法的内容长度标题域。

对回应消息来说，消息中是否包含实体主体取决于请求方法和回应代码。所有的HEAD
请求方法的回应都不应包括主体，即便是实体标题域中指明有主体也一样。在主体中不应包
括这些回应信息，全部1xx（信息）、204（无内容）和304（未修改）。而其它的回应必须包
括实体主体或其内容长度标题（Content-Length header）域的定义值为0。

9 连接
　 RTSP请求可以几种不同方式传送：
　 1、持久传输连接，用于多个请求/回应传输。
　 2、每个请求/回应传输一个连接。
　 3、无连接模式。
　 传输连接类型由RTSP URI来定义。对 \"rtsp\" 方案，需要持续连接；而\"rtspu\"方案，
调用RTSP 请求发送，而不用建立连接。
　 不象HTTP，RTSP允许媒体服务器给媒体用户发送请求。然而，这仅在持久连接时才支持，否则媒体服务器没有可靠途径到达用户，这也是请求通过防火墙从媒体服务器传到用户的唯一途径。

9.1 流水线操作
　 支持持久连接或无连接的客户端