libwebsockets中实现HTTP摘要认证的正确方式

在基于libwebsockets开发HTTPS客户端时，实现HTTP摘要认证(Digest Authentication)是一个常见需求。许多开发者会遇到认证流程处理不当的问题，特别是当服务器返回401未授权响应后，如何正确继续认证流程。

常见误区

开发者通常会尝试在收到401响应后，直接通过lws_write()函数发送带有Authorization头的新GET请求。这种做法看似合理，但实际上会导致连接关闭，请求无法被正确处理。这是因为：

1. libwebsockets的连接模型设计为每个HTTP事务使用独立的连接
2. 底层会根据HTTP版本(1.0/1.1/HTTP2)自动优化连接重用
3. 直接写入的方式绕过了库的连接管理机制

正确实现方式

正确的做法是建立一个新的客户端连接。libwebsockets内部会智能处理连接重用：

1. 对于HTTP/1.0：每次都需要新建TCP连接
2. 对于HTTP/1.1：可能重用现有连接进行事务链式处理
3. 对于HTTP/2：可以在已建立的连接上多路复用新事务

这种设计的原因在于客户端在初始连接时无法预知服务器将使用哪种HTTP版本，或者中间是否存在中转服务。

实现步骤

1. 首次连接服务器，获取401响应和nonce值
2. 根据服务器返回的认证信息构造Authorization头
3. 使用lws_client_connect_via_info()创建新的客户端连接
4. 在新连接的请求中携带认证头信息
5. libwebsockets会自动处理底层连接优化

性能考虑

虽然看起来需要多次连接，但libwebsockets会在可能的情况下优化：

• 对于HTTP/1.1和HTTP/2，已建立的连接会保持一段时间(可配置)
• 在此期间的新连接会复用现有连接
• HTTP/2连接会自动多路复用请求，减少延迟

这种设计既保证了正确性，又兼顾了性能，是libwebsockets连接模型的优势所在。

通过遵循这一模式，开发者可以可靠地实现HTTP摘要认证，同时充分利用libwebsockets提供的连接优化机制。