rtsp协议 编码_udp协议_视频编码协议(12)

start-line = Request-Line | Status-Line

为了健壮性考虑，服务器应该忽略任何在期望收到请求行时收到的空行。换句话说，如果服务器正在读协议流，在一个消息开始时如果首先收到了CRLF，这个CRLF符应被忽略。

4.2 消息标题

见[H4.2]。

RTSP标题域，包括主标题（General-Header,4.3节）、请求标题（Request-Header ,5.2节）、

回应标题（Response-Header ,6.2节）及实体标题（Entity-Header,7.1节），都遵照RFC822-3.1

节[7]给出的通用式定义。每个标题域由后紧跟冒号的名字，单空（SP），字符及域组

成。域名是大小写敏感的。虽然不提倡，标题域还是可以扩展成多行使用，只要这些行以一

个以上的SP或HT开头就行。rtsp协议 编码

RTSP-header = field-name ":" [ field-value ] CRLF

field-name = token

field-value = *( field-content | LWS )

field-content = <the OCTETs make up the field-value

and consisting of either *TEXT or combinations

of token, tspecials, and quoted-string>

标题域接收的顺序并不重要，但良好的习惯是，先发送主标题，然后是请求标题或回应

标题，最后是实体标题。

当且仅当标题域的全部域都用逗号分隔的列表示时（即，#（）），多个有相同域名

的RTSP标题域才可以表示在一个消息里。而且必须能在不改变消息语法的前提下，将并发

的域加到第一个后面，之间用逗号分隔，最终能将多个标题域结合成“域名：域”对。

4.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. 任何回应消息都不包含消息主体（如1××，204和304回应），并且不管消息中是否存在实体标题域都以消息标题域后的第一行空行表示结束。

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