附录 B. 'charset' 参数的部署考虑

B.1. 用户代理

未实现 'charset' 的用户代理将像以前一样继续工作，忽略新参数。

已默认使用 UTF-8 编码的用户代理按定义实现了 'charset'。

其他用户代理可以保持其默认行为，并在看到新参数时切换到 UTF-8。

B.2. 服务器

不支持凭据中非 US-ASCII 字符的服务器不需要任何更改来支持 'charset'。

需要支持非 US-ASCII 字符但无法使用 UTF-8 字符编码方案的服务器不会受到影响；它们将继续像以前一样良好或糟糕地运行。

最后，需要支持非 US-ASCII 字符并且可以使用 UTF-8 字符编码方案的服务器可以通过在认证质询中指定 'charset' 参数来选择加入。理解 'charset' 参数的客户端将开始使用 UTF-8，而其他客户端将继续以其默认编码、损坏的凭据或根本不发送凭据。在所有客户端都升级为支持 UTF-8 之前，服务器可能会在请求中看到 UTF-8 和 "遗留" 编码。当 UTF-8 处理失败时（由于无法解码为 UTF-8 或用户 ID/密码不匹配），服务器可能会尝试回退到之前支持的遗留编码，以适应这些遗留客户端。请注意，隐式重试需要谨慎进行；例如，某些子系统可能会检测到重复的登录失败并将其视为潜在的凭据猜测攻击。

B.3. 为何不直接将默认编码切换为 UTF-8?

今天使用的某些站点默认使用本地字符编码方案，例如 ISO-8859-1 ([ISO-8859-1])，并期望用户代理使用该编码。如果用户代理切换到不同的编码（如 UTF-8），这些站点上的认证将停止工作。

请注意，站点甚至可能检查 User-Agent 头字段（[RFC7231]，第 5.5.3 节）以决定从客户端期望哪种字符编码方案。因此，它们可能对某些用户代理支持 UTF-8，但对其他用户代理默认使用其他编码。后一组中的用户代理将必须继续执行它们今天所做的事情，直到大多数这些服务器已升级为始终使用 UTF-8。

---