txiki.js中fetch方法GET请求默认发送null body的问题分析

txiki.js是一个轻量级的JavaScript运行时环境，最近在开发过程中发现其fetch API实现存在一个值得注意的行为差异问题。当开发者使用fetch方法发起GET请求时，即使没有显式设置请求体(body)，系统也会默认发送一个内容为"null"的请求体，这可能导致与某些服务器的兼容性问题。

问题现象

通过实际测试可以观察到以下现象：

1. 当执行fetch('http://localhost:9999')时，虽然请求方法是GET，但会自动包含一个内容为"null"的请求体，并附带Content-Length和Content-Type头部
2. 这种行为与fetch('http://localhost:9999', {method: 'GET', body: null})完全一致
3. 相比之下，HEAD方法则不会发送任何请求体
4. 如果显式设置空字符串作为body(body: '')，则会发送正确的空请求体

技术分析

这个问题涉及到HTTP协议规范和fetch API实现的几个关键点：

1. HTTP协议规范：根据RFC 7231，GET和HEAD方法本质上不应该包含请求体。虽然协议没有明确禁止，但大多数服务器实现会忽略或拒绝GET请求中的请求体。

2. fetch API设计：现代fetch API的设计理念是保持一致性，即允许所有HTTP方法都可以携带请求体，但默认情况下GET/HEAD等方法不应该自动添加请求体。

3. txiki.js实现问题：当前实现中，当body参数未设置时，内部可能默认将其转为null值，而不是忽略请求体。这导致了不符合预期的行为。

4. 头部字段大小写问题：观察中还注意到content-type头部字段的大小写不一致问题，这虽然不影响功能，但反映了内部实现可能存在标准化处理不足的情况。

解决方案与最佳实践

该问题已被项目维护者修复，主要改动包括：

1. 对于GET/HEAD等不应该有请求体的方法，不再自动添加null body
2. 确保头部字段的大小写一致性
3. 只有当开发者显式设置body参数时才会包含请求体

对于开发者而言，在使用fetch API时应该注意：

1. 避免为GET请求设置请求体，除非明确知道服务器支持这种用法
2. 如果确实需要发送数据，考虑使用POST方法或将数据编码到URL查询参数中
3. 对于需要空body的情况，显式设置body: ''比依赖默认行为更可靠

总结

这个案例展示了JavaScript运行时实现细节对开发者体验的影响。txiki.js作为新兴的JavaScript运行时，正在不断完善其API的实现细节，使其更符合Web标准和开发者预期。理解这些底层行为差异有助于开发者编写更健壮、可移植的代码。

对于服务器端开发者而言，也应该注意处理可能收到的非常规请求，比如带body的GET请求，以提供更好的兼容性和健壮性。