RPC 失败和 http.postBuffer

Azure DevOps Services |Azure DevOps Server |Azure DevOps Server 2022

如果您在RPC failedgit push期间看到错误，例如：

  • error: RPC failed; result=22, HTTP code = 404
  • error: RPC failed; result=22, HTTP code = 411
  • Unable to rewind rpc post data - try increasing http.postBuffer error: RPC failed; result=56, HTTP code = 0

...并在 Stack Overflow 或 MSDN 论坛上搜索帮助，你将看到许多要设置 http.postBuffer的旧建议。

别这样！ 至少不要盲目行动。 首先，查看本文中的建议。

升级 Git

如果仍在运行版本 2.8 或更高版本的 Git 客户端，则应先升级 Git。 较新版本的 Git 中的 bug 修复应该能省去设置 http.postBuffer 的需要。

我们收到了大量来自内部用户和外部客户的支持请求，他们在旧版 Git 中遇到了 bug，因此我们决定在 Azure DevOps Services/TFS 中添加服务器端提醒。

c:\mydir>git fetch
remote: Microsoft (R) Visual Studio (R) Team Services
remote: We noticed you're using an older version of Git. For a better experience, upgrade to the latest version at https://git-scm.com/downloads
remote: Found 4 objects to send. (6 ms)
Unpacking objects: 100% (4/4), done.

检查修补程序

检查这些修补程序是否适用，前提是 TFS 服务器正在运行 Windows 2012 R2 或更早版本：

检查你是否正在使用代理或负载均衡器

如果您使用一个问题不断或不稳定且不支持分块编码的代理，您会在进行较大推送时看到错误。 如果将本地 TFS 部署在配置不当的负载均衡器后面，可能会发生相同的问题。 如果绕过代理或负载均衡器（例如，从服务器本身推送到 localhost）的情况下仍然成功，那么就需要修复你的代理或负载均衡器！

如果代理或负载均衡器损坏，但无法控制它，该怎么办？

这是我们所看到的唯一一种情况，其中设置 http.PostBuffer 对较新版本的 Git 非常有用。

http.postBuffer 问题

设置 http.postBuffer 是否有害？

在我们的经验中，它比有害更不必要，但有一些负面影响：

  • 将它增大到默认值上方可能会增加较大推送的延迟（因为客户端会将 HTTP 请求缓冲到更大的区块中）。
  • 在将其设置为大于 HTTP 服务器的 HTTP 区块大小限制（例如，对于 TFS 服务器中的 maxAllowedContentLength 和 maxRequestLength）时，所有超过区块大小限制的推送都会开始失败。

如果已设置，如何取消设置 http.postBuffer ？

若要检查是否已设置，请运行：

git config --show-origin --get-all http.postBuffer

你可能必须在你的全局 .gitconfig 文件中取消配置它：

git config --global --unset http.postBuffer

以及存储库级别 .git/config （覆盖全局设置）：

git config --local --unset http.postBuffer
  • Last updated on