Question

我有一个Django应用，该应用在调用API时会返回一个较大的JSON。问题是当我请求数据时，数据本身被截断了，这使前端崩溃。

我正在将Cloud Front用于DNS和SSL以及它们提供的其他功能以进行缓存和提高性能。

我尝试卷曲API，并收到以下错误：

卷曲：（92）HTTP / 2流1没有完全关闭：INTERNAL_ERROR（错误2）

我尝试禁用Cloudflare，但是没有用。但是，在我的本地主机上，一切正常。

HTTP / 2流1没有完全关闭：INTERNAL_ERROR（错误2） *关闭连接0 * TLSv1.2（OUT），TLS警报，客户端问候（1）： curl：（92）未彻底关闭HTTP / 2流1：INTERNAL_ERROR（错误2）

应该完全获取JSON，而不要分块。

Answer 1

AWS的应用程序负载平衡器（ALB）遇到了这个问题。问题是我将Apache配置为使用http2，但位于ALB后面。默认情况下，ALB支持http2：

应用程序负载平衡器通过HTTPS侦听器为HTTP / 2提供本机支持。您可以使用一个HTTP / 2连接并行发送多达128个请求。负载平衡器将这些请求转换为单独的HTTP / 1.1请求，并将它们分布在目标组中的正常目标中。由于HTTP / 2可以更有效地使用前端连接，因此您可能会注意到客户端与负载平衡器之间的连接较少。您不能使用HTTP / 2的服务器推送功能。 1

因此，curl使用HTTP / 2与ALB连接，然后将其转换为HTTP / 1请求。 Apache正在向响应中添加标头，以要求客户端将Upgrade发送到HTTP / 2，ALB刚刚将其传递回客户端，并且curl读取它为无效，因为它已经在使用HTTP / 2连接。我通过在Apache实例上禁用HTTP / 2解决了该问题。由于它将始终位于ALB的后面，并且ALB永远不会使用HTTP / 2，因此没有必要使用它。

Answer 2

修复或删除HTTP请求中的Content-Length标头。

发生此问题时，我试图连接到AWS Gateway。我可以使用POSTMAN获得正确的响应，但是如果我将相同的标头复制到curl，则会出现此错误。

最终对我有用的是删除Content-Length标头，因为curl中的请求长度与POSTMAN中的请求长度不匹配。

由于在我的情况下，我仅测试API，所以还可以，但是我不建议在生产中删除此标头。如果代码库中发生这种情况，请检查以确保正确计算了长度。

Answer 3

使用Nginx，通过让两个http2虚拟主机监听相同的服务器名称，您可以在curl中遇到此错误。在nginx配置文件上运行检查将引发警告，通知您某些错误。修复/删除重复的列表可以解决此问题。

# nginx -t
nginx: [warn] conflicting server name "example.com" on 0.0.0.0:443, ignored
nginx: [warn] conflicting server name "example.com" on [::]:443, ignored

Answer 4

我在使用 AWS Application Load Balancer 时遇到了同样的错误，它似乎不支持 HTTP/2，使用命令：

curl "https://console.aws.example/api/xxx" -b "SESSION=$SESSION"

<块引用>

15:14:30 curl：(92) HTTP/2 流 1 没有完全关闭： PROTOCOL_ERROR（错误 1）

我不得不强制使用带有参数 --http1.1

的 HTTP/1.1

所以最后的命令是：

curl "https://console.aws.example/api/xxx" -b "SESSION=$SESSION" --http1.1

请求大数据时，出现“卷曲：（92）HTTP / 2流1未完全关闭：INTERNAL_ERROR（err 2）”

4 个答案: