curl 作者 Daniel Stenberg 发布博客称，随着 HTTP/3（基于 QUIC 实现）逐渐普及，QUIC 的 API 缺失问题是一个关键问题。他提到，多年前就实现了许多现有的 QUIC 库，而且它们正在慢慢成熟。QUIC 协议也成为了 RFC 9000，但最流行的 TLS 库仍然没有提供必要的 API 让 QUIC 库可以使用它们。

据介绍，很长时间以来，QUIC 社区的许多成员和项目都在热切地关注 OpenSSL 的 Pull Request 8797，该 PR 将必要的 QUIC API 引入了 OpenSSL。此变更给 OpenSSL 带来了与 BoringSSL 已经提供的相同的 API，该 API 已经被多个独立实现使用和测试。

不过基于 BoringSSL 的实现有一个问题，因为它是一个没有版本和真正发行版的 TLS 库，所以对大多数人来说它不是一个好的选择。毕竟 OpenSSL 已经是最广泛使用的 TLS 库，并且已经有许多应用程序在使用它。

2020 年 2 月，OpenSSL PR8797 被宣布推迟实现，当时 OpenSSL 管理委员会 (OMC) 表示他们在 3.0.0 版本发布之前不会处理该 PR。2021 年 3 月，微软和 Akamai 宣布了 quictls，这是一个 OpenSSL 分支，其明确的想法是提供 OpenSSL + QUIC API。他们不想等待 OpenSSL 来完成这件事。

部分 QUIC 库现在已经可以使用 quictls。quictls 可以让他们的分支保持最新状态，现在提供了等同于 OpenSSL 3.0.0 + QUIC API 的实现。

与此同时，许多人仍在一直在等待 OpenSSL 采用 API。

10 月 13 日，OpenSSL OMC 宣布：

下一个版本的重点是 QUIC，目标是在一系列版本 (2-3) 上提供功能齐全的 QUIC 实现。

由此可见，OpenSSL 已经决定自己实现一个完整的 QUIC 堆栈，并且按照给定的时间线，听起来他们需要几年 (?) 才能发布。并且没有提供许多实现者已经等待这么久的 API：

MVP 将不包含用于 HTTP/3 实现的库 API。

Daniel 表示，他没有编写自己的 QUIC 实现，但非常密切地跟踪了几个实现的工作，这些开发者为自己制定了相当复杂的安排——原因不清楚。他认为现在已经存在多个高质量的 QUIC 库，为什么 OpenSSL 认为他们还需要自己制作另一个？

2021 年 10 月 20 日，于 2019 年 4 月创建的 OpenSSL Pull Request 8797 最终被标记为"wont fix"，并被关闭。

Daniel 表示，他对此感到失望。OpenSSL 缺少 QUIC API 将会造成阻碍，而 QUIC 堆栈将不得不坚持使用或切换到其他库。