3 支持的 Mochitest 框架简介¶

Mochitest 框架目前使用 httpd.js 作为其主要的 HTTP 服务器，该服务器仅支持 HTTP/1.1。为了提高我们在 necko 中对 HTTP/2 和 HTTP/3 的测试能力，我们改进了 Mochitest 框架，使 Firefox 在运行 Mochitest 文件时能够使用 HTTP/2 或 HTTP/3 连接到测试服务器。

HTTP/1.1 的 Mochitest 框架服务器设置¶

如下图所示，有一个后端 HTTP 服务器在 http://127.0.0.1:8888 运行。为了确保 Firefox 可以使用单个 HTTP 服务器访问多个来源，Mochitest 框架使用了代理自动配置 (PAC)。这个 PAC 脚本确保所有普通 HTTP 连接都代理到 127.0.0.1:8888。

对于 HTTPS 连接，Mochitest 框架在 HTTP 服务器和浏览器之间集成了一个额外的 SSL 代理。最初，Firefox 向代理发送 CONNECT 请求以建立隧道。设置成功后，代理继续将数据中继到服务器。

graph LR A[Firefox] -->|请求| B[SSL 代理] B -->|请求| C["后端服务器 (127.0.0.1:8888)<br/>处理 *.sjs、*.html、*.jpg 等"] C -->|响应| B B -->|响应| A

HTTP/2 和 HTTP/3 的 Mochitest 框架服务器设置¶

下图显示了 HTTP/2 和 HTTP/3 的架构。

graph LR A[Firefox] -->|请求| B[反向代理] B -->|请求| C["后端服务器 (127.0.0.1:8888)<br/>处理 *.sjs、*.html、*.jpg 等"] C -->|响应| B B -->|响应| A A -->|DNS 查询| D[DoH 服务器] D -->|DNS 响应| A

后端服务器¶

这与现有的 httpd.js 相同。

反向代理¶

我们的反向代理位于后端服务器前面，拦截 Firefox 请求。反向代理充当 Firefox 的 HTTP/2 或 HTTP/3 连接的网关，接受这些请求并将它们转换为 HTTP/1.1 格式，然后再转发到后端服务器。从后端服务器接收响应后，反向代理随后将此响应转发回 Firefox。

DoH 服务器¶

为了将 HTTP 请求路由到反向代理服务器，我们需要配置一个 DoH 服务器。DoH 服务器应该为每个 A/AAAA DNS 查询返回 127.0.0.1。此外，DoH 服务器还会返回 HTTPS RR，原因如下：通过 HTTPS RR 中提供的端口信息，我们可以将 server-locations.txt 中的所有不同端口号映射到反向代理使用的端口号。通过 HTTPS RR 中定义的“alpn”，Firefox 将自动执行 HTTPS 升级并与反向代理服务器建立 HTTP/2 或 HTTP/3 连接。

如何在本地使用 HTTP/2 或 HTTP/3 运行测试¶

要使用 HTTP/2 执行测试，请包含 --use-http2-server 选项。以下是一个示例

./mach mochitest --use-http2-server PATH_TO_TEST_FILE

对于 HTTP/3 测试，请将选项切换到 --use-http3-server。如下所示

./mach mochitest --use-http3-server PATH_TO_TEST_FILE

跳过测试的原因¶

我们有一些测试目前在 HTTP/2 和 HTTP/3 服务器上失败，因此暂时跳过了这些测试。导致这些失败的原因有几个

意外的 HTTPS 升级

HTTP/2 和 HTTP/3 仅支持 HTTPS，这导致我们无一例外地将所有普通 HTTP 请求升级到 HTTPS。此更改导致某些测试失败，因为它们期望方案保持 HTTP。例如，此测试期望接收方的来源为 http://mochi.test:8888。
缺少某些功能的服务器支持

例如，HTTP/3 服务器目前不支持 websocket，因此 dom/websocket/test 中的所有测试都已跳过。
与 HTTPS 不兼容

某些测试并非设计为与 HTTPS 一起运行。对于这些测试，跳过它们是我们的唯一选择。