Txiki.js 中 XMLHttpRequest 重用时的段错误问题分析

问题背景

在 JavaScript 运行时环境 Txiki.js 中，开发者发现当重用 XMLHttpRequest (XHR) 对象时，如果第二次请求没有设置任何 HTTP 头部，会导致程序出现段错误(Segmentation Fault)。这是一个典型的 C 语言内存访问违规问题，需要深入分析其根本原因。

问题复现

问题可以通过以下测试用例复现：

import assert from 'tjs:assert';

const url = 'https://postman-echo.com/get';
const xhr = new XMLHttpRequest();
xhr.open('GET', url, false);
xhr.setRequestHeader('Content-Type', 'application/json');
xhr.send();

xhr.open('POST', url, false);
xhr.send();  // 此处发生段错误

技术分析

Txiki.js 底层使用 libcurl 来处理 HTTP 请求。在 XHR 实现中，当重用 XHR 对象时：

1. 第一次请求设置了 'Content-Type' 头部
2. 第二次请求没有设置任何头部
3. 底层代码没有正确处理头部链表为 NULL 的情况

在 libcurl 中，CURLOPT_HTTPHEADER 选项需要显式设置为 NULL 当没有头部时。原始代码中使用了条件判断，只有当头部链表存在时才设置这个选项，这导致了不一致的状态。

解决方案

正确的做法是无论是否有头部，都应该显式设置 CURLOPT_HTTPHEADER 选项。当没有头部时，传递 NULL 值。修改后的代码如下：

curl_easy_setopt(x->curl_h, CURLOPT_HTTPHEADER, x->slist);

这个修改确保了 libcurl 总是能获取到明确的头部状态指示，避免了未定义行为。

深入理解

这个问题揭示了几个重要的编程实践：

1. API 契约：libcurl 的文档明确指出，当没有头部时应该传递 NULL，这不是可选的行为
2. 状态一致性：重用对象时需要确保所有相关状态都被正确重置
3. 防御性编程：即使某些路径理论上不会被执行，也应该处理所有可能的状态

最佳实践

在使用类似 libcurl 的 C 库时，开发者应该：

1. 仔细阅读文档，了解每个选项的预期行为
2. 显式处理所有可能的状态，包括 NULL 或空值情况
3. 在重用对象时，确保所有相关状态都被正确重置
4. 编写全面的测试用例，覆盖边界条件

这个问题的修复不仅解决了段错误，也使代码更加健壮和符合 libcurl 的设计预期。