TR-069第一期第六修正版-8

今天看的是会话部分。是TR交互的一个基础。

3.4.2 会话Sessions

对于形成单个会话的一系列事务transactions，CPE应在会话期间保持TCP连接。具体而言，CPE不得在会话期间关闭TCP连接。如果在HTTP请求/响应交互之后TCP连接完全关闭，并且在最后一次HTTP响应之后，会话没有以其他方式终止（成功或失败），则CPE必须通过在新的TCP连接中发送下一个HTTP请求来继续会话。

Kevin：这里的会话指HTTP会话。在会话中CPE不能终止TCP连接。一个会话中会有多个transactions。当会话没有结束时，CPE应该建立一个新的TCP连接。换句话说，CPE不能以成功的状态正常终止会话。

注意-最理想的情况是每个会话使用一个TCP连接，因为重新协商连接会使用额外的资源（网络套接字、网络带宽、处理能力），这会增加系统过载和会话中断的可能性，进而增加负载。

收到认证挑战（authentication challenge）后，CPE必须在同一TCP连接中发送下一个HTTP请求（包括“Authorization”HTTP头），除非ACS通过“Connection: close”HTTP头明确请求关闭TCP连接。在后一种情况下，CPE必须接受ACS请求，关闭TCP连接，并在新的TCP连接中发送下一个HTTP请求（包括“Authorization”HTTP头）。

如果CPE由于任何原因未能建立TCP连接，无法发送HTTP消息，或未能接收HTTP响应，CPE必须认为会话未成功终止。CPE必须等待至少30秒，然后才能宣布无法建立TCP连接或无法接收HTTP响应。

如^[11]所述，ACS应使用会话cookie来维护会话状态。ACS应仅使用标记为Discard的cookie，并且假设CPE不会在会话持续时间之外维护cookie。

为了确保ACS可以使用会话cookie，CPE必须支持使用[^11]中定义的cookie，包括在每个后续HTTP POST中返回cookie值，但CPE不需要支持在会话持续时间之外存储cookie。CPE必须支持ACS使用多个cookie，并且必须提供至少512字节的cookie存储空间。

注意-在处理使用本规范以前版本的ACS时，可能会使用老式的“Netscape”cookie。

当会话成功完成或终止失败时，CPE必须关闭与ACS的相关TCP连接。

CPE必须支持ACS使用HTTP重定向。对于使用HTTP重定向的CPE和ACS，要求如下：

• CPE必须支持302（Found）和307（Temporary Redirect）HTTP状态码。

• CPE可能还可以支持用于重定向的301（Moved Permanently永久移动）HTTP状态码。

• CPE必须允许在会话期间的任何时间点（包括InformResponse）发生重定向，ACS可以在会话期间的任何时间点发出重定向。

• 如果CPE被重定向，CPE必须尝试使用HTTP重定向响应中提供的URL继续会话。具体来说，CPE必须将导致重定向响应的HTTP POST重新发送到重定向URL处的ACS，然后CPE必须尝试继续会话，就像没有发生重定向一样。

• 如果CPE被重定向，则重定向的URL必须仅应用于当前会话的其余部分，或者直到同一会话稍后发生后续重定向。CPE不得保存重定向的URL（即^[27]、^[34]和^[35]中定义的ManagementServer.URL的值），以用于任何后续会话或会话的任何后续重试。即使301（Moved Permanently）HTTP状态代码用于重定向，该要求也必须成立。

• CPE必须允许最多5次连续重定向。如果CPE连续重定向5次以上，则可能会认为会话未成功终止。

• HTTP重定向中提供的URL可以是HTTP或HTTPS URL。无论重定向之前使用了何种传输，新目标都必须使用相应的传输机制（TCP或TLS）。

• 如果TLS用于重定向会话，要求CPE对ACS进行身份验证，则身份验证必须基于重定向的URL，而不是预先配置的ACS URL（参见第3.3节）。

• 在ACS发送的包含重定向状态代码的HTTP响应中，HTTP entity-body（第3.3节/RFC7230^[6]）的长度必须为零。如果CPE接收到带有非空 entity-body的HTTP重新定向响应，它必须忽略 entity-body的内容。

• 当被重定向时，CPE必须在随后发给重定向ACS的HTTP请求中包含与会话相关的所有cookie。CPE必须认为从ACS重定向为在[^11 ]中定义的“可验证事务verifiable transaction”，因此必须在不对每个Cookie的域验证的情况下将所有Cookie发送到重定向的ACS。