Поделиться через

Сбои в работе RPC и http.postBuffer

Azure DevOps Services | Azure DevOps Server 2022 — Azure DevOps Server 2019

Если во время git pushотображается ошибка RPC failed, например:

  • 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

Если вы по-прежнему работаете с клиентом Git версии 2.8 или более ранней, сначала следует обновить Git. Есть исправления ошибок в новых версиях Git, которые должны устранить необходимость в настройке http.postBuffer.

У нас было достаточно запросов на поддержку от внутренних пользователей и внешних клиентов, столкнувшихся с ошибками в старых версиях Git, поэтому мы решили добавить уведомление на стороне сервера в 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-сервера (например, maxAllowedContentLength и maxRequestLength в web.config для серверов TFS), тогда все отправки, превышающие это ограничение, начнут завершаться с ошибкой.

Как отменить настройку 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