Git:错误:RPC失败；curl 92 HTTP/2 流 0 未完全关闭:PROTOCOL_ERROR (err 1) [英] Git : error: RPC failed; curl 92 HTTP/2 stream 0 was not closed cleanly: PROTOCOL_ERROR (err 1)

问题描述

请不要在未阅读完整问题的情况下将此标记为重复.

当我尝试将代码推送到我们的存储库时，出现以下错误:

我尝试在网络上搜索这个问题，我发现了惊人的资源，但不是确切的解决方案.有很多类似的问题，但我没有找到明确的讨论或适当的解决方案.

我提到了这个 问题.我还研究了提供相应答案的那些答案和参考资料.

我按照此答案的建议增加了缓冲区大小，但对我不起作用.

我按照 answer 中的建议将 HTTP 版本从 HTTP/2 降级到 HTTP/1.1，它对我有用.

我提到了一个评论，他提到为什么我们必须将 HTTP 版本从 HTTP/2 降级到 HTTP/1.1.我不明白他的评论.下面是他的评论.

<块引用>

在回答关于降级到HTTP/1.1的问题时，OP发布的错误消息指出了HTTP/2的问题；超出 OP 控制的某些东西(代理、GIT 服务器等)很可能不适用于 HTTP/2.在解决此问题之前，降级到 HTTP/1.1 是一种有效的解决方法.

所以我的问题是

1. 为什么要将 HTTP 版本从 HTTP/2 降级到 HTTP/1.1?
2. 为什么 增加缓冲区大小的解决方法并非对所有人都有效?

解决方案

所以我的问题是

1. 为什么要将 HTTP 版本从 HTTP/2 降级到 HTTP/1.1?

我们不应该——但请看下文.

<块引用>

1. 为什么 增加缓冲区大小的解决方法并非对所有人都有效?

这也应该是不必要的.

这里可能存在几个不同的问题，但如果您的网络连接基本完好(并非所有问题都是如此)，那么 HTTP 或 HTTPS 协议问题的常见来源是某种中间件盒，例如试图阻止访问的过滤器到未经批准的主机，即未正确过滤.也就是说，您尝试直接连接到例如 github.com，但不是连接到 github.com，而是连接到某个公司服务器.公司服务器检查 Web 请求，决定是允许还是拒绝它，并在决定允许后，自己的 连接到 github.com，然后开始中继流量.

问题在于，执行此中继的中间件服务器损坏了数据.

正确修复是修复或移除中间件服务器.其他任何事情都只是一种解决方法.如果电话中继接线员 Bob 一直告诉您 Susan 不在办公室，即使她在办公室，您也不再向 Bob 询问有关 Susan 的事情.相反，您要求 Bob 将您连接到她的办公室同事 Suzie.Bob 现在将您连接到 Susan(显然也叫 Suzie)，您就可以完成工作了.这并不意味着每个人都必须叫她 Suzie，事实上，如果只有 Bob 叫她 Suzie，你的朋友，她的电话是通过 Fred 而不是 Bob，不能要求 Suzie:这对 Fred 不起作用.

由于计算机中继比混乱的电话运营商更复杂，因此使用 ssh:// URL 可能比 http:// 或 https 更成功:// 网址.但是适合您的任何解决方法，让您摆脱数据损坏问题，适合您.它可能对其他人不起作用，但这无论如何都不是正确的解决方法.正确的解决方法是移除或更换损坏的过滤器/继电器.

Please don't mark this a duplicate without reading full question.

When I was trying to push my code to our repository, I got below error:

I tried to search this issue on web and I found amazing resources but not exact solution. There were many similar question but I didn't find clear discussion or proper solution.

I referred this question. I also looked into those answers and references which provides on respective answers.

I increased a buffer size as suggested on this answer but not worked for me.

I downgrade HTTP version from HTTP/2 to HTTP/1.1 as suggested on this answer and it worked for me.

I referred One comment where he mentioned that why we've to downgrade HTTP version from HTTP/2 to HTTP/1.1. I didn't understand his comment. Below one is his comment.

In reply to questions about downgrading to HTTP/1.1, the error message posted by OP points to an issue with HTTP/2; it is likely that something beyond OP's control (a proxy, the GIT server, etc.) does not work well with HTTP/2. Until that's fixed, downgrading to HTTP/1.1 is a valid workaround.

So my questions are

1. Why should we downgrade HTTP version from HTTP/2 to HTTP/1.1?
2. Why increasing the buffer size workaround is not working for everyone?

解决方案

So my questions are

1. Why should we downgrade HTTP version from HTTP/2 to HTTP/1.1?

We shouldn't—but see below.

2. Why increasing the buffer size workaround is not working for everyone?

This should also be unnecessary.

There can be several different problems here, but if your network connection is fundamentally sound—not all are—then the usual source of HTTP or HTTPS protocol issues is some sort of middleware box, such as a filter that tries to prevent access to unapproved hosts, that is not filtering correctly. That is, you attempt to connect directly to, e.g., github.com, but instead of getting connected to github.com you get connected to some corporate server. The corporate server checks the web request, decides whether to allow or deny it, and upon deciding to allow it, makes its own connection to github.com and then starts relaying traffic.

The problem is that this middleware server, that does this relaying, corrupts the data.

The correct fix is to fix or remove the middleware server. Anything else is merely a workaround. If Bob, the phone relay operator, consistently tells you that Susan is out of the office even when she is in, you stop asking Bob about Susan. Instead, you ask Bob to connect you to her office-mate Suzie. Bob now connects you to Susan (who apparently also goes by the name Suzie) and you're able to get your work done. This does not mean that everyone has to call her Suzie, and in fact, if only Bob calls her Suzie, your friend, whose calls go through Fred instead of Bob, can't ask for Suzie: that won't work with Fred.

Because computer relays are more complicated than confused phone operators, you may have better success using ssh:// URLs than http:// or https:// URLs. But any workaround that works for you, that gets you past the data corruption problem, is fine for you. It might not work for anyone else, but this isn't the right fix anyway. The right fix is to remove or replace the broken filter/relay.

这篇关于Git:错误:RPC失败；curl 92 HTTP/2 流 0 未完全关闭:PROTOCOL_ERROR (err 1)的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！