openfire 服务器处理XML节的规则

原创作品，允许转载，转载时请务必以超链接形式标明文章  原始出处  、作者信息和本声明。否则将追究法律责任。 http://blog.csdn.net/love254443233/article/details/7850075

处理XML节的服务器规则

每个服务器实现将包含它自己的处理接受的节的逻辑. 这写逻辑决定服务器是需要路由一个给定的节到其他域, 还是把它递送到一个本地实体(典型的是一个和本地帐号相关联的已连接客户端), 或者直接由服务器本身处理它. 本章提供处理XML节的通用规则. 然而, 特殊的XMPP应用可以定义递送规则来修改或补充以下规则(例如, 定义于XMPP‑IM的用于即时消息和联机状态信息应用的一系列递送规则).

顺序处理

一个XMPP服务器必须确保它从一个已连接的客户端或远端服务器的给定的入站流上收到的节和其他XML元素的顺序处理.

顺序处理适用于 (a) 任何用来协商和管理XML流的XML元素, 和 (b) 所有XML节, 包括但不限于以下情况:

1. 由一个客户端发送到它的服务器或它自己的纯JID的由服务器直接处理的节(例如, XMPP‑IM所述的获取好友名册和初始化出席信息的顺序处理).
2. 由一个已连接的客户端发送的节并且是用来递送到另一个和该服务器相关的实体(例如, 从地址 <juliet@im.example.com> 发到 <nurse@im.example.com> 的节). 服务器必须确保按照从发送的客户端的入站流上接收到节的顺序来递送那些到预期接收者的节, 对递送目的接收者地址为纯JID和全JID的节等同对待.
3. 由一个已连接的客户端发送的节并且是用来递送到一个位于远端服务器上的实体(例如, 从地址 <juliet@im.example.com> 发到 <romeo@example.net>). 路由的服务器必须确保按照从发送的客户端的入站流上接收到节的顺序来路由那些到预期接收者的节, 对路由目的接收者地址为纯JID和全JID的节等同对待. 为了帮助确保顺序处理, 路由服务器必须通过单一的到远端域的出站流来路由这些节, 而不是在一个服务器－服务器流上发送一些节而在另一个服务器－服务器流上发送另一些节.
4. 从一个服务器路由到另一个服务器的递送到远端服务器的一个相关实体的节(例如, 从地址 <juliet@im.example.com> 发到 <romeo@example.net> 并且由 <im.example.com> 在一个服务器－服务器流上路由到 <example.net>). 递送服务器必须确保按照它从路由服务器的入站流上接收到的顺序来递送节, 对递送目的接收者地址为纯JID和全JID的节同等对待.
5. 由一个服务器发送到另一个服务器用于远端域直接处理的节(例如, 从 <im.example.com> 发到 <example.net>).

如果服务器对于特定请求的处理对它接下来可能从入站流收到的数据的处理有影响(例如, 强制性的通讯策略), 它必须挂起接下来的数据的处理，直到它已经处理完该请求.

顺序处理只适用于单一入站流. 所以, 服务器不负责保证它从相同本地帐号(例如, 通过两个不同入站流从<juliet@im.example.com/balcony> 和 <juliet@im.example.com/chamber>接收到的节) 或相同的远端域(例如, 由一个远端域通过两个不同的入站流进行的流协商; 然而, 服务器可以以<conflict/>流错误来关闭该流(4.9.3.3),如果远端服务器尝试协商多个流, 详见4.9.3.3)通过多个入站流接收到的数据的相干性.

一般注意事项

在顶层, 服务器处理XML节有三个主要的注意事项, 它们有时候相左但需要一个一致的办法来管理:

1. 如果可能最好把一个节递送到预定的接收者.
2. 如果一个节不能被递送, 通知发送者是有帮助的.
3. 促成目录获取攻击(13.11)和联机状态泄露(13.10.2)是不好的.

对于可能的和递送相关的攻击, 以下几点需要牢记:

1. 从攻击者的视角来看, 在服务器 (i) 递送节或存储成离线消息稍后递送(见[{RFC6121|XMPP‑IM]]) 和 (ii) 安静地忽略它(因为在任何那种用例之下都不会立刻返回一个错误)之间是否有任何一点有效的不同; 因此, 在服务器递送一个节或吧这个节离线存储稍后递送的场景中, 如果那个帐号不存在，它需要安静地忽略这个节.
2. 服务器如何处理发送到一个受到目录获取影响的纯JID<localpart@domainpart>的节, 因为如果服务器根据一个给定的纯JID是否有帐号来做出不同应答，那么攻击者可以确定一个帐号是否存在.
3. 服务器如何处理发送到一个受到出席信息泄露影响的全JID的节, 因为可以发送请求到多个全JID上并且根据该用户是否有一个全JID的设备在线来收到不同的应答. 使用随机的资源部分(是由客户端还是服务器生成参见第七章)明显减轻了这个攻击, 所以在某种程度上它被关心的程度地狱目录获取攻击.

很自然, 如果收到从一个用户的服务器返回的错误的实体已经知道用户的出席信息或被授权知道它，那么出席信息就没有被泄露(例如, 所谓出席信息订阅或直接的出席信息), 如果服务器返回一个错误给一个已经知道某用户存在的实体，那么该服务器没有受到目录获取攻击(例如, 因为实体在用户的联系人列表里); 这些事情的更完整的讨论见XMPP‑IM.

没有'to'地址

如果节没有'to'属性, 服务器必须代表发送它的实体来直接处理它, 这里"直接处理它"的含义依赖于这个节是 message, presence, 还是 IQ. 因为从其它服务器收到的所有节必须拥有'to'属性, 这个规则只适用于从连接到该服务器的本地实体(通常是一个客户端)收到的节.

Message

如果该服务器接收到一个没有'to'属性的message节, 它必须把这个消息当作'to'地址是发送实体的纯JID <localpart@domainpart> 那样来处理.

Presence

如果该服务器接收到一个没有'to'属性的presence节, 它必须广播这个节到订阅了发送者实体的出席信息的实体, 如果适用的话(XMPP‑IM定义了出席信息应用的这类广播的语义).

IQ

如果服务器接收到一个没有'to'属性的IQ节, 它必须代表发送这个节的帐户处理这个节, 如下:

1. 如果IQ节的类型为"get"或"set"并且服务器理解限定载荷的命名空间, 该服务器必须代表发送实体处理该节或返回一个适当的错误给发送实体. 尽管"处理"的含义是由限定的命名空间的语义来决定的, 通常服务器将返回一个适当的类型为"result"或"error"的IQ节来应答类型为"get"或"set"的节, 应答就好像服务器就是发送实体的纯JID那样. 作为一个例子, 如果发送实体发送一个类型为"get"而载荷由'jabber:iq:roster'命名空间限定(参见XMPP‑IM)的IQ节, 那么服务器将返回和该发送实体的纯JID相关的roster给请求roster的发送实体的特定资源.
2. 如果IQ节的类型为"get"或"set"并且服务器不理解限定该载荷的命名空间, 服务器必须返回一个错误给发送实体, 这个错误必须是<service-unavailable/>.
3. 如果IQ节的类型是"error"或"result", 该服务器必须根据该IQ相关的载荷或类型是"get"或类型是"set"处理这个error或result(如果没有相关的节, 服务器必须忽略该error或result节).

远程域

如果JID的域部分包含一个'to'属性但是和该服务器配置的任何一个完整合格域名(FQDNs)都不匹配, 该服务器应该尝试路由该节到远端域(服从本地服务器关于域间通讯的规定和安全策略, 因为对于任何给定的部署来说这类通讯是可选的). 如下章所述, 有两个可能的用例.

安全警告: 这些规则仅适用于客户端-服务器流. 如8.1.1.2所述, 如果'to'属性里的JID的域部分和接收服务器的完全合格域名(FQDN)不匹配，那么服务器不能(MUST NOT)在一个服务器-服务器流上接收节.

现有流

如果一个服务器-服务器流已经存在于两个域之间, 发送者的服务器应该尝试在现有的流上为远端服务器路由这个节到授权服务器.

无现有流

如果在两个域之间无现有的服务器-服务器流, 发送者的服务器将如下处理:

1. 解析远端域的完整合格域名(FQDN)(如13.9.2所述).
2. 在两个域之间协商服务器-服务器流(如第五章和第六章所述).
3. 在新建的流上为远端域路由该节到授权服务器.

错误处理

如果一个到预期接收者服务器的节的路由不成功, 发送者的服务器必须返回一个错误给发送者. 如果远端域的解析不成功, 节错误必须是 <remote-server-not-found/> (8.3.3.16). 如果成功解析但是流无法协商, 节错误必须是<remote-server-timeout/> (8.3.3.17).

如果和期望的接收者的服务器的流协商成功了但是远端服务器不能递送该节到接收者, 远端服务器必须通过发送者的服务器返回一个适当的错误给发送者.

本地域

如果包含在'to'属性中的JID的域部分和该服务器的完整合格域名(FQDN)匹配, 该服务器必须首先确定该FQDN是由服务器本身还是由特定的本地服务来提供服务. 如果是后者, 该服务器必须路由该节到那个服务. 如果是前者, 该服务器必须执行接下来的动作. 无论如何, 该服务器不能(MUST NOT)路由或"转发"该节到另一个域, 因为处理所有'to'地址的域部分和该服务器的已配置FQDN匹配的节是服务器的责任(除此之外, 这还可以防止循环处理).

域部分

如果包含在'to'属性里的JID的格式为<domainpart>, 那个么该服务器必须要么 (a) 根据节类型做适当的处理，要么 (b) 返回一个错误节给发送者.

域部分/资源部分

如果包含在'to'属性中的JID的格式为<domainpart/resourcepart>, 那么该服务器必须要么 (a) 根据节类型做适当处理，要么 (b) 返回一个节错误给发送者.

本地部分@域部分

这种类型的地址通常和该服务器上的一个帐号相关. 以下规则提供一些通用方针; 更多即时消息和出席信息场景中的详细规则参见XMPP‑IM.

没有此用户

如果没有本地帐号和<localpart@domainpart>相关, 节被如何处理取决于节的类型.

1. 对于message节 该服务器必须要么 (a) 安静地忽略该节，要么 (b) 返回一个<service-unavailable/>节错误(8.3.3.19)给发送者.
2. 对于presence节, 该服务器应该忽略该节(或如XMPP‑IM所述那样表现).
3. 对于IQ节, 该服务器必须返回一个<service-unavailable/>节错误(8.3.3.19)给发送者.

用户存在

如果包含在'to'属性中的JID的格式为<localpart@domainpart>, 节如何被处理取决于节类型.

1. 对于message节, 如果该帐号存在至少一个已连接的资源那么该服务器应该递送这个节到至少一个已连接的资源. 如果不存在已连接的资源，那么该服务器必须要么 (a) 离线存储该message等该帐号下次有已连接资源时递送，要么 (b) 返回一个<service-unavailable/>节错误(8.3.3.19).
2. 对于presence节, 如果存在一个已连接的资源曾经发送过初始presence (即, 有一个如XMPP‑IM所述的"presence会话")，那么该服务器应该递送该节到那个资源. 如果不存在已连接的资源，那么服务器应该忽略该节(或如XMPP‑IM那样表现).
3. 对于IQ节, 服务器必须直接代表预期的接收者来处理它.

本地部分@域部分/资源部分

如果包含在'to'属性中的JID的格式为<localpart@domainpart/resourcepart>而且该用户存在但是没有已连接的资源能和该全JID精确匹配, 该节应该如10.5.3.2所述的JID格式为<localpart@domainpart>时那样地被处理.

如果包含在'to'属性中的JID的格式为<localpart@domainpart/resourcepart>, 该用户存在, 并且有一个已连接的资源和该全JID精确地匹配, 该服务器必须递送该节到那个已连接的资源.