确保数据大小不-ruby on rails web开发学习实录 高清扫描版 pdf下载

发送这些响应的服务器实现体必须处理流控制。特别的，它们必须：（1）确保数据大小不 超过优先传输的可用窗体大小，或者（2）使用非阻塞式写入。 5.4. 自动注销计时器 如果服务器有一个静止的自动注销计时器，那么这个计时器的持续时间必须不少于 30 分钟。 在这个间隔里，来自客户端的任何命令应当重设这个自动注销计时器。 5.5. 多个命令在行进中 受多义规则（见下）和优先数据流的流控制约束的影响，客户端可能不等到一个命令的完成 结果响应就发送另外一个命令。类似的，受多义规则的影响， 服务器可能在处理当前命令 的实现前，就开始处理另外一个命令。不过，在任何后续命令初始化前，任何连续请求响应 和连续命令必须协调。 因为一个命令可能影响到其它命令的结果，一个多义可能导致异常。客户端不应当未等待一 个多义的返回结果就发送多个命令。如果服务器发现了一个可能存在的多义，它必须按照客 户端给出的顺序完成命令的执行。 最常见的多义例子是，一个命令可能影响其它命令的结果，例如，一个邮件标记的 FETCH 和同一个邮件标记的 STORE。 一个不常见的多义例子是，允许一个非标签化 EXPUNGE 响应的命令（除了 FETCH， STORE，SEARCH），因为一个非标签化响应可以 使一个后续命令的序列号无效。这个 问题不会发生于 FETCH，STORE，或者 SEARCH 命令，因为这些命令中的任何一个在行 进中时，服务器禁止发送 EXPUNGE 响应。因此，如果客户端发送 FETCH，STORE，或 者 SEARCH 之外的任意命令，则必须在发送一个带有邮件序列号的命令前，就等待直 至 得到完成结果响应。 注意：UID FETCH，UID STORE，和 UID SEARCH 命令不同于 FETCH，STORE，和 SEARCH。如果客户端发送了一个 UID 命令，它必须在发送一个带有邮件序列号的命令前， 就等待直至得到一个完成结果响应。 例如，下面的非等待式命令序列是无效的： FETCH + NOOP + STORE STORE + COPY + FETCH COPY + COPY CHECK + FETCH 下面是有效的非等待式命令序列的例子： FETCH + STORE + SEARCH + CHECK STORE + COPY + EXPUNGE UID SEARCH + UID SEARCH 非等待命令序列可能有效，可能无效，这取决于第二个 UID SEARCH 是否包含邮件序列号。 6. 客户端命令 本节描述 IMAP4rev1 命令。这些命令按照其被允许的状态组织。被多种状态允许的命令， 只在其被允许的最小状态里列出（例如，在登录和选中状态都有效的命令，在登录状态中列 出）。