Waku开发服务器中304状态码被错误转换为404的问题分析

在Waku框架的0.21.0-beta.4版本中，开发环境下出现了一个关于HTTP状态码处理的异常问题。当开发服务器(Vite)返回304(Not Modified)状态码时，Waku框架会错误地将其转换为404(Not Found)状态码，导致应用无法正常运行。

问题现象

在开发模式下启动Waku应用后，浏览器请求某些资源时，Vite开发服务器正确地返回了304状态码，表示资源未被修改可以使用缓存版本。然而，Waku框架在处理这个响应时，错误地将304状态码转换为了404状态码，同时响应体(body)也被置为undefined，导致应用功能异常。

问题根源分析

经过深入分析，问题主要出在Waku框架的两个关键处理环节：

1. 中间件响应处理逻辑：Waku框架在处理开发服务器响应时，对于没有响应体(body)的情况，直接返回了null，这导致后续流程将请求视为404错误。

2. Hono运行器处理逻辑：框架在判断是否返回响应时，仅检查了响应体(body)是否存在，而没有同时考虑HTTP状态码。这使得即使服务器返回了有效的304状态码，也会因为没有响应体而被错误处理。

解决方案

针对这个问题，开发团队提出了两种解决方案：

1. 中间件层修复：在中间件中显式处理304状态码的情况，确保即使没有响应体也不会被错误转换。具体做法是为304响应添加一个空的ReadableStream作为响应体。

2. 核心逻辑修复：修改Hono运行器的响应判断逻辑，不仅检查响应体，也检查状态码。这样即使没有响应体，只要状态码有效(如304)，请求也能被正确处理。

最终，开发团队选择了第二种更为根本的解决方案，修改了核心响应处理逻辑，确保304状态码能够被正确传递和处理。

技术要点

1. HTTP 304状态码是服务器告诉客户端可以使用缓存版本的响应，按照规范不应该包含响应体。

2. 现代前端开发服务器(如Vite)会合理利用304状态码优化开发体验，减少不必要的资源传输。

3. 框架在设计响应处理管道时，需要特别注意无响应体但有状态码的情况，这是符合HTTP规范的常见场景。

这个问题虽然只在开发环境下出现，但对于开发者体验影响较大。通过这次修复，Waku框架对HTTP规范的支持更加完善，开发模式下的热更新和缓存机制也能更可靠地工作。