Mongoose项目中HTTP/HTTPS同时访问时的Cookie冲突问题解析

2025-05-20 08:06:48作者：钟日瑜

**Mongoose：轻量级网络引擎，释放设备互联的无限可能** Mongoose是一个成熟且强大的C/C++编写的嵌入式网络库，自2004年起，它已在全球数百万产品中大放异彩，甚至在国际空间站上运行！这个库通过简洁的非阻塞API，支持TCP、UDP、HTTP、WebSocket、MQTT等多种协议，简化物联网设备和应用程序的网络编程。无论是Linux、Windows还是各类微控制器，Mongoose都能实现“编写一次，处处运行”的高效开发体验。内置丰富协议栈与TLS安全支持，加上极小的资源占用，使得在最小化系统中集成复杂网络功能成为轻而易举之事。从工业自动化到家用智能设备，Mongoose都是构建可靠、响应迅速的网络服务的得力助手。快来探索如何用这不到6文件的精简代码，在裸机平台上打造出功能完备的Web控制面板吧！深入了解与实践，尽在[mongoose.ws](https://mongoose.ws/)。

项目地址：https://gitcode.com/gh_mirrors/mong/mongoose

在Mongoose项目开发过程中，当Web UI Dashboard同时支持HTTP和HTTPS协议访问时，开发者可能会遇到一个典型的Cookie冲突问题。这个问题表现为：当用户先通过HTTPS登录后，再通过HTTP访问时，部分页面内容无法正常显示。

问题现象分析

当服务端同时开启8000(HTTP)和8443(HTTPS)端口时，会出现以下异常情况：

单独使用HTTP访问时，所有功能页面都能正常显示
一旦有用户通过HTTPS登录后，HTTP访问的Dashboard、Settings和Events页面会显示空白
通过浏览器开发者工具查看，会发现HTTP请求返回403未授权错误

根本原因

这个问题源于现代浏览器对Cookie的安全策略限制。当HTTPS连接设置了Secure属性的Cookie后，浏览器会阻止HTTP连接设置同名的Cookie。具体表现为：

HTTPS连接设置的Cookie会自动添加Secure属性
当HTTP尝试设置同名Cookie时，浏览器会拒绝并显示警告："尝试通过Set-Cookie标头设置Cookie的操作被禁止了，因为此标头不是通过安全连接发送的，而且会覆盖具有Secure属性的Cookie"
导致HTTP请求无法携带有效的认证令牌，服务端返回403未授权响应

解决方案

Mongoose项目团队提出了两种解决方案：

为HTTPS连接添加前缀标识
最初尝试在HTTPS的Cookie值前添加"s_"前缀，但测试发现这种方法无效，因为浏览器是根据Cookie名而非值来判断冲突的。
使用不同的Cookie名称
最终有效的解决方案是为HTTP和HTTPS连接使用完全不同的Cookie名称：

static void handle_login(struct mg_connection *c, struct user *u) {
  char cookie[256];
  const char *cookie_name = c->is_tls ? "secure_access_token" : "access_token";
  mg_snprintf(cookie, sizeof(cookie),
              "Set-Cookie: %s=%s; Path=/; "
              "%sHttpOnly; SameSite=Lax; Max-Age=%d\r\n",
              cookie_name, u->access_token, 
              c->is_tls ? "Secure; " : "", 3600 * 24);
  mg_http_reply(c, 200, cookie, "{%m:%m}", MG_ESC("user"), MG_ESC(u->name));
}

技术要点总结

Cookie的Secure属性：标记为Secure的Cookie只能通过HTTPS连接传输，这是浏览器的重要安全特性。
同源策略下的Cookie处理：即使协议不同(HTTP/HTTPS)，浏览器仍视为同一来源，会对同名Cookie进行安全校验。
服务端适配：在同时支持HTTP和HTTPS的服务中，需要对认证机制做特殊处理，避免协议间的Cookie冲突。

这个问题很好地展示了在实际开发中，安全策略与功能需求之间的平衡考量。通过为不同协议使用不同的Cookie名称，既满足了浏览器的安全要求，又实现了双协议支持的功能需求。

mongoose