首页 > 解决方案 > Getting "curl: (92) HTTP/2 stream 1 was not closed cleanly: INTERNAL_ERROR (err 2)"

问题描述

I have a Django app which returns a large JSON while calling an API. The problem is when I'm requesting the data, the data itself is truncated which is crashing the frontend.

I'm using cloud front for DNS and SSL and other feature provided by them for caching and improved performance.

I tried curling the API and got the following error from curl:

curl: (92) HTTP/2 stream 1 was not closed cleanly: INTERNAL_ERROR (err 2)

I tried disabling the Cloudflare but didn't work. On my localhost, however, everything works fine.

HTTP/2 stream 1 was not closed cleanly: INTERNAL_ERROR (err 2)

  • Closing connection 0
  • TLSv1.2 (OUT), TLS alert, Client hello (1): curl: (92) HTTP/2 stream 1 was not closed cleanly: INTERNAL_ERROR (err 2)

The JSON should be fetched entirely without getting chunked.

标签: djangoamazon-web-servicesrestcurlcloudflare

解决方案


我在使用 AWS 的 Application Load Balancer (ALB) 时遇到了这个问题。这个问题是我将 Apache 配置为使用 http2,但在 ALB 之后。ALB 默认支持 http2:

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

因此,curl 使用 HTTP/2 与 ALB 连接,然后将其转换为 HTTP/1 请求。Apache 在请求客户端到 HTTP/2 的响应中添加了标头,UpgradeALB 刚刚将其传递回客户端,并且 curl 将其读取为无效,因为它已经在使用 HTTP/2 连接。我通过在我的 Apache 实例上禁用 HTTP/2 解决了这个问题。因为它总是在 ALB 之后,而且 ALB 永远不会使用 HTTP/2,所以没有它的意义。


推荐阅读