我有一个Django应用程序，它在调用API时返回一个大的JSON。 问题是当我请求数据时，数据本身被截断，导致前端崩溃。
我正在使用云前端进行DNS和SSL以及它们提供的其他功能，以进行缓存和提高性能。
我尝试卷曲 API，并从 curl 收到以下错误：
curl： (92) HTTP/2 流 1 没有完全关闭： INTERNAL_ERROR (err 2)
我尝试禁用Cloudflare，但没有工作。但是，在我的本地主机上，一切正常。
HTTP/2 流 1 未完全关闭：INTERNAL_ERROR(错误 2)
- 关闭连接 0
- TLSv1.2 (OUT)， TLS alert， Client hello (1)： curl： (92) HTTP/2 流 1 未完全关闭： INTERNAL_ERROR (err 2)
应该完全获取 JSON，而不会被分块。
我在使用AWS 应用程序负载均衡器后面的应用程序时遇到了相同的错误，使用以下命令：
curl "https://console.aws.example/api/xxx" -b "SESSION=$SESSION"
14：30 curl： (92) HTTP/2 流 1 未完全关闭： PROTOCOL_ERROR(错误 1)
我不得不强制使用HTTP/1.1与参数--http1.1
所以最后一个命令是：
curl "https://console.aws.example/api/xxx" -b "SESSION=$SESSION" --http1.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，因此没有必要拥有它。
修复或删除 HTTP 请求中的Content-Length标头。
当我遇到此问题时，我正在尝试连接到 AWS 网关。我能够使用 POSTMAN 获得正确的响应，但是如果我将相同的标头复制到curl，它会给我这个错误。
最终对我有用的是删除Content-Length标头，因为curl中请求的长度与 POSTMAN 中的长度不匹配。
因为就我而言，我只是在测试 API，所以这很好，但我不建议在生产中删除这个标头。检查以确保长度计算正确，如果这种情况发生在代码库中。
使用 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
我这边的问题出在响应标头"Upgrade"=h2,h2c中。 例如，来自 curl -v 的扩展响应：
* http2 error: Invalid HTTP header field was received: frame type: 1, stream: 1, name: [upgrade], value: [h2,h2c]
* HTTP/2 stream 0 was not closed cleanly: PROTOCOL_ERROR (err 1)
* stopped the pause stream!
我将这个标题设置为空Upgrade: ""，http2 上的 curl 开始正常工作。