rtsp协议 编码_海康rtsp协议_http 协议(13)

********************

4.3 消息主体

见[H4.3]。

********************

[H4.3]：

RTSP消息的消息主体（如果有）用来携带请求或响应的主体。仅在使用传输编码(Transfer-Encoding)时消息主体和实体主体才有所不同，这种情况在传输编码头部域中有详细说明。（见[H14.40]）

message-body = entity-body

| <entity-body encoded as per Transfer-Encoding>

传输编码必须能解释所有保证传输安全和正确的应用程序的传输编码。传输编码是消息而不是实体的一个属性，因此可以由任一应用程序随着请求/响应链添加或者删除。

什么时候允许消息带消息体的规则在请求和响应两种情况下有所不同。

在请求中有无消息主体的标志是是否包含内容长度或请求消息头部域中的传输编码头部域。只有当请求方法允许有实体主体的时候才能在请求中包含消息主体。

而对于响应消息来说，无论消息中是否存在消息主体都与请求方法和响应状态编码无关。所有响应头部请求方法的消息都不能包含消息主体，尽管有时会因为存在实体头部域而使人产生误解。所有1××（信息），204（无内容），304（未修改）响应都不包含消息主体。而其他响应则都包含主体，尽管其长度有可能长度为零。

********************

4.4 消息长度

当信息体包含在信息中时，信息体长度由如下因素决定（按优先度排列）：

1.任何【必须不】包含消息体messagebody的响应消息（如1XX，204，及304响应），总是在头域后的第一个空行后就结束，而不管实体头部域是否出现在信息中。（注意：空行中只有CRLF。）

2.如果存在内容长度头部域（Content-Lengthheader field），它的（单位为byte）就表示消息体的长度。如果此头部域没有出现，则假设其为0。

3.通过服务器关闭连接。（关闭连接不能被用于指示请求主体（request body）的结束，因为那样将使服务器无法回送响应。）

注意：RTSP目前并不支持HTTP/1.1"块"传输编码(见 [H3.6])，需要有内容头部域。

假如返回了长度适当的表示描述，服务器应该总是可以确定它的长度--即便它是动态产生，使得没有必要采用块传输编码。如有实体，即使必须有内容长度，且长度没显式给出，上述规则也可确保行为的合理性。

5 普通头部域

除了Pragma、Transfer-Encoding和 Upgrade头部，其余见[H4.5]

general-header =Cache-Control ; Section 12.8

| Connection; Section 12.10

|Date; Section 12.18

|Via; Section 12.43

6 请求

从客户端到服务器端或与之相反的请求消息，在消息首行中包括：应用于资源的方法、资源的标识符及所使用的协议。

Request = Request-Line ; 6.1节

*( general-header ; 5章

| request-header ; 6.2节

| entity-header ) ; 8.1节

CRLF

[ message-body ] ; 4.3节

6.1 请求行

请求行 = 方法 空请求-URI 空 RTSP-版本 CRLF

Method="DESCRIBE"; Section 10.2

本文来自电脑杂谈，转载请注明本文网址：
http://www.pc-fly.com/a/tongxinshuyu/article-47669-13.html