Rpc failed http 413 curl 22 the requested url returned error 413

stupid issue with Github going on right now. I have a decent amount of changes (~120MB in size), when I attempt to push, this is what happens: error: RPC failed; result=22, HTTP code = 413 fatal: ...

https clone of gists fails (ssh works, see below):

12:00 jean@laptop:~/tmp$ GIT_CURL_VERBOSE=1 git clone https://gist.github.com/123456.git username
Initialized empty Git repository in /home/jean/tmp/username/.git/
* Couldn't find host gist.github.com in the .netrc file; using defaults
* About to connect() to gist.github.com port 443 (#0)
*   Trying 192.30.252.142... * Connected to gist.github.com (192.30.252.142) port 443 (#0)
* found 141 certificates in /etc/ssl/certs/ca-certificates.crt
*        server certificate verification OK
*        common name: *.github.com (matched)
*        server certificate expiration date OK
*        server certificate activation date OK
*        certificate public key: RSA
*        certificate version: #3
*        subject: C=US,ST=California,L=San Francisco,O=GitHub, Inc.,CN=*.github.com
*        start date: Mon, 30 Apr 2012 00:00:00 GMT
*        expire date: Wed, 09 Jul 2014 12:00:00 GMT
*        issuer: C=US,O=DigiCert Inc,OU=www.digicert.com,CN=DigiCert High Assurance CA-3
*        compression: NULL
*        cipher: ARCFOUR-128
*        MAC: SHA1
> GET /123456.git/info/refs?service=git-upload-pack HTTP/1.1
User-Agent: git/1.7.1
Host: gist.github.com
Accept: */*
Pragma: no-cache

< HTTP/1.1 301 Moved Permanently
< Server: GitHub.com
< Date: Fri, 01 Nov 2013 05:00:51 GMT
< Content-Type: text/html
< Content-Length: 178
< Location: https://gist.github.com/gist/123456.git/info/refs?service=git-upload-pack
< Vary: Accept-Encoding
<
* Ignoring the response-body
* Expire cleared
* Connection #0 to host gist.github.com left intact
* Issue another request to this URL: 'https://gist.github.com/gist/123456.git/info/refs?service=git-upload-pack'
* Couldn't find host gist.github.com in the .netrc file; using defaults
* Re-using existing connection! (#0) with host gist.github.com
* Connected to gist.github.com (192.30.252.142) port 443 (#0)
> GET /gist/123456.git/info/refs?service=git-upload-pack HTTP/1.1
User-Agent: git/1.7.1
Host: gist.github.com
Accept: */*
Pragma: no-cache

< HTTP/1.1 200 OK
< Server: GitHub.com
< Date: Fri, 01 Nov 2013 05:00:52 GMT
< Content-Type: application/x-git-upload-pack-advertisement
< Transfer-Encoding: chunked
< Expires: Fri, 01 Jan 1980 00:00:00 GMT
< Pragma: no-cache
< Cache-Control: no-cache, max-age=0, must-revalidate
< Vary: Accept-Encoding
<
* Connection #0 to host gist.github.com left intact
* Couldn't find host gist.github.com in the .netrc file; using defaults
* About to connect() to gist.github.com port 443 (#0)
*   Trying 192.30.252.142... * connected
* Connected to gist.github.com (192.30.252.142) port 443 (#0)
* found 141 certificates in /etc/ssl/certs/ca-certificates.crt
* SSL re-using session ID
*        server certificate verification OK
*        common name: *.github.com (matched)
*        server certificate expiration date OK
*        server certificate activation date OK
*        certificate public key: RSA
*        certificate version: #3
*        subject: C=US,ST=California,L=San Francisco,O=GitHub, Inc.,CN=*.github.com
*        start date: Mon, 30 Apr 2012 00:00:00 GMT
*        expire date: Wed, 09 Jul 2014 12:00:00 GMT
*        issuer: C=US,O=DigiCert Inc,OU=www.digicert.com,CN=DigiCert High Assurance CA-3
*        compression: NULL
*        cipher: ARCFOUR-128
*        MAC: SHA1
> POST /123456.git/git-upload-pack HTTP/1.1
User-Agent: git/1.7.1
Host: gist.github.com
Accept-Encoding: deflate, gzip
Content-Type: application/x-git-upload-pack-request
Accept: application/x-git-upload-pack-result
Content-Length: 116

< HTTP/1.1 301 Moved Permanently
< Server: GitHub.com
< Date: Fri, 01 Nov 2013 05:00:53 GMT
< Content-Type: text/html
< Content-Length: 178
< Location: https://gist.github.com/gist/123456.git/git-upload-pack
< Vary: Accept-Encoding
<
* Ignoring the response-body
* Connection #0 to host gist.github.com left intact
* Issue another request to this URL: 'https://gist.github.com/gist/123456.git/git-upload-pack'
* Violate RFC 2616/10.3.2 and switch from POST to GET
* Couldn't find host gist.github.com in the .netrc file; using defaults
* Re-using existing connection! (#0) with host gist.github.com
* Connected to gist.github.com (192.30.252.142) port 443 (#0)
> GET /gist/123456.git/git-upload-pack HTTP/1.1
User-Agent: git/1.7.1
Host: gist.github.com
Accept-Encoding: deflate, gzip
Content-Type: application/x-git-upload-pack-request
Accept: application/x-git-upload-pack-result

* The requested URL returned error: 400
* Closing connection #0
error: RPC failed; result=22, HTTP code = 400

This works: git clone git@gist.github.com:123456.git

Источник

https clone of gists fails (ssh works, see below):

12:00 jean@laptop:~/tmp$ GIT_CURL_VERBOSE=1 git clone https://gist.github.com/123456.git username
Initialized empty Git repository in /home/jean/tmp/username/.git/
* Couldn't find host gist.github.com in the .netrc file; using defaults
* About to connect() to gist.github.com port 443 (#0)
*   Trying 192.30.252.142... * Connected to gist.github.com (192.30.252.142) port 443 (#0)
* found 141 certificates in /etc/ssl/certs/ca-certificates.crt
*        server certificate verification OK
*        common name: *.github.com (matched)
*        server certificate expiration date OK
*        server certificate activation date OK
*        certificate public key: RSA
*        certificate version: #3
*        subject: C=US,ST=California,L=San Francisco,O=GitHub, Inc.,CN=*.github.com
*        start date: Mon, 30 Apr 2012 00:00:00 GMT
*        expire date: Wed, 09 Jul 2014 12:00:00 GMT
*        issuer: C=US,O=DigiCert Inc,OU=www.digicert.com,CN=DigiCert High Assurance CA-3
*        compression: NULL
*        cipher: ARCFOUR-128
*        MAC: SHA1
> GET /123456.git/info/refs?service=git-upload-pack HTTP/1.1
User-Agent: git/1.7.1
Host: gist.github.com
Accept: */*
Pragma: no-cache

< HTTP/1.1 301 Moved Permanently
< Server: GitHub.com
< Date: Fri, 01 Nov 2013 05:00:51 GMT
< Content-Type: text/html
< Content-Length: 178
< Location: https://gist.github.com/gist/123456.git/info/refs?service=git-upload-pack
< Vary: Accept-Encoding
<
* Ignoring the response-body
* Expire cleared
* Connection #0 to host gist.github.com left intact
* Issue another request to this URL: 'https://gist.github.com/gist/123456.git/info/refs?service=git-upload-pack'
* Couldn't find host gist.github.com in the .netrc file; using defaults
* Re-using existing connection! (#0) with host gist.github.com
* Connected to gist.github.com (192.30.252.142) port 443 (#0)
> GET /gist/123456.git/info/refs?service=git-upload-pack HTTP/1.1
User-Agent: git/1.7.1
Host: gist.github.com
Accept: */*
Pragma: no-cache

< HTTP/1.1 200 OK
< Server: GitHub.com
< Date: Fri, 01 Nov 2013 05:00:52 GMT
< Content-Type: application/x-git-upload-pack-advertisement
< Transfer-Encoding: chunked
< Expires: Fri, 01 Jan 1980 00:00:00 GMT
< Pragma: no-cache
< Cache-Control: no-cache, max-age=0, must-revalidate
< Vary: Accept-Encoding
<
* Connection #0 to host gist.github.com left intact
* Couldn't find host gist.github.com in the .netrc file; using defaults
* About to connect() to gist.github.com port 443 (#0)
*   Trying 192.30.252.142... * connected
* Connected to gist.github.com (192.30.252.142) port 443 (#0)
* found 141 certificates in /etc/ssl/certs/ca-certificates.crt
* SSL re-using session ID
*        server certificate verification OK
*        common name: *.github.com (matched)
*        server certificate expiration date OK
*        server certificate activation date OK
*        certificate public key: RSA
*        certificate version: #3
*        subject: C=US,ST=California,L=San Francisco,O=GitHub, Inc.,CN=*.github.com
*        start date: Mon, 30 Apr 2012 00:00:00 GMT
*        expire date: Wed, 09 Jul 2014 12:00:00 GMT
*        issuer: C=US,O=DigiCert Inc,OU=www.digicert.com,CN=DigiCert High Assurance CA-3
*        compression: NULL
*        cipher: ARCFOUR-128
*        MAC: SHA1
> POST /123456.git/git-upload-pack HTTP/1.1
User-Agent: git/1.7.1
Host: gist.github.com
Accept-Encoding: deflate, gzip
Content-Type: application/x-git-upload-pack-request
Accept: application/x-git-upload-pack-result
Content-Length: 116

< HTTP/1.1 301 Moved Permanently
< Server: GitHub.com
< Date: Fri, 01 Nov 2013 05:00:53 GMT
< Content-Type: text/html
< Content-Length: 178
< Location: https://gist.github.com/gist/123456.git/git-upload-pack
< Vary: Accept-Encoding
<
* Ignoring the response-body
* Connection #0 to host gist.github.com left intact
* Issue another request to this URL: 'https://gist.github.com/gist/123456.git/git-upload-pack'
* Violate RFC 2616/10.3.2 and switch from POST to GET
* Couldn't find host gist.github.com in the .netrc file; using defaults
* Re-using existing connection! (#0) with host gist.github.com
* Connected to gist.github.com (192.30.252.142) port 443 (#0)
> GET /gist/123456.git/git-upload-pack HTTP/1.1
User-Agent: git/1.7.1
Host: gist.github.com
Accept-Encoding: deflate, gzip
Content-Type: application/x-git-upload-pack-request
Accept: application/x-git-upload-pack-result

* The requested URL returned error: 400
* Closing connection #0
error: RPC failed; result=22, HTTP code = 400

This works: git clone git@gist.github.com:123456.git

Источник

Содержание

  1. Ошибка Github Push: ошибка RPC; result = 22, HTTP-код = 413
  2. Решение для nginx
  3. Решение для Apache

Ошибка Github Push: ошибка RPC; result = 22, HTTP-код = 413

глупая проблема с Github происходит прямо сейчас. У меня приличное количество изменений (

120 МБ), когда я пытаюсь нажать, вот что происходит:

git config http.postBuffer 524288000 , так что, похоже, проблема не в этом. Что бы это могло быть?

Я понял это. Конечно, я бы сразу после того, как ударил пост!

У меня был набор репо для использования HTTPS-url, я изменил его на SSH-адрес, и все возобновилось, работая безупречно.

Если вы получаете ошибку 413, проблема не связана с git, а с вашим веб-сервером.
Это ваш веб-сервер, который блокирует большие файлы для загрузки.

Решение для nginx

Просто загрузите nginx.conf и добавьте client_max_body_size 50m; (изменив значение в соответствии с вашими потребностями) в блоке http.

Перезагрузите nginx, чтобы принять новый конфиг, выполнив sudo service nginx reload и повторите попытку, чтобы нажать фиксацию поверх http.

Решение для Apache

В httpd.conf добавьте LimitRequestBody 52428800 (изменив значение в соответствии с вашими потребностями) внутри блока . При этом вы можете ограничить запрос всей файловой системы сервера, всего одного виртуального хоста или каталога.

Надеюсь, это поможет.

для изменения удаленного URL (из https → git @…) есть что-то вроде этого

происхождение здесь – это имя моего удаленного (сделать git remote, а то, что выдается, – это ваше происхождение).

У меня была та же проблема, но я использовал обратный прокси.

Поэтому мне пришлось установить

внутри обоих файлов конфигурации:

  • на веб-сервере gitlab nginx (как указано в предыдущих ответах)
  • , но также и на обратном прокси nginx, размещенном на выделенном сервере.

У меня уже был “HTTPS//” в URL git, но он столкнулся с этой ошибкой.

Все, что я делал, это добавить опцию -u с push и она сработала.

git push -u origin master

Для тех, кто использует IIS 7 для размещения конечной точки git http / https :

Вам нужно увеличить uploadReadAheadSize .

Запустить Диспетчер служб IIS

Разверните поле “Сервер”

Выберите сайт, для которого вы хотите внести изменения.

В разделе “Функции” дважды щелкните Configuration Editor

В разделе Section выберите: system.webServer > serverRuntime

Измените раздел uploadReadAheadSize (значение должно быть между 0 и 2147483647 .)

Если вы столкнулись с этой проблемой во время изменения большого размера, выполните команду ниже в терминале.

Смотрите это для более подробной информации.

У меня возникла эта проблема, когда я пытаюсь клонировать репозиторий git на машине Linux.

для меня в Windows работает следующий URL:

тогда как следующий URL-адрес работает на машине Linux и имеет https в URL

https clone of gists терпит неудачу (ssh работает, см. ниже):

Это работает: git clone git@gist.github.com:123456.git

У меня была эта ошибка (ошибка: RPC failed; result = 22, HTTP code = 413), когда я попытался выполнить мою первоначальную фиксацию в новом репозитории BitBucket. Ошибка произошла для меня, потому что у репликации BitBucket была ветвь без мастера. Если вы используете SourceTree, вы можете создать главную ветвь в начале координат, нажав кнопку Git Flow.

Ошибка возникает в ‘libcurl’, который является базовым протоколом для загрузки https. Решение – как-то обновить libcurl.
Чтобы получить более подробную информацию об ошибке, установите GIT_CURL_VERBOSE = 1

Значение ошибки, согласно libcurl doc:
CURLE_HTTP_RETURNED_ERROR (22)

Это возвращается, если для параметра CURLOPT_FAILONERROR установлено значение ИСТИНА, а HTTP-сервер возвращает код ошибки >= 400.

У меня была такая же проблема (в Win XP), я обновил файл libcurl-4.dll в моем каталоге bin Git до версии SSL из http://www.paehl.com/open_source/?download=curl_DLL_ONLY.7z (переименование в libcurl4.dll). Теперь все работает нормально.

Столкнулась с такой же проблемой.
В моем случае это были несовместимые версии GIT для нескольких пользователей, которые обращаются к одному и тому же проекту (pull/push).

только что обновили версию GIT и обновили путь к настройкам студии Android, и она отлично работает для меня.

Git для Windows (1.9.5) с некоторыми проблемами, обновление может помочь.

Столкнулась с одной и той же проблемой, однако она была решена путем очистки хранилища git (очистить невоспроизводимые файлы с помощью “git clean” ).

Нужно изменить удаленный URL на SSH или HTTPS

Надеюсь, это поможет 🙂

Используете ли вы ссылки https вместо ссылок ssh? Поскольку ссылка https ограничена размером загрузки HttpServer (например, Apache, Ngnix), при использовании ssh такого ограничения нет.

Используйте следующий метод для переключения на ссылку ssh.

  1. Откройте терминал.
  2. Переключитесь на рабочий каталог вашего проекта.
  3. Получить имя удаленного хранилища
  1. Измените адрес git на ссылку ssh.

Если вы определите имя удаленного репозитория, перейдите непосредственно к шагу 4. Теперь вы можете успешно выполнить операцию push.

Когда я использовал URL-адрес https для отправки на удаленный мастер, я столкнулся с той же проблемой, я изменил его на адрес SSH, и все возобновило работу без нареканий.

Источник

Источник

preface

Recently, one of my team members told me that he couldn’t git commit code. I asked the reason and he said he would report the code as soon as it was submitted

error: RPC failed; HTTP 413 curl 22 The requested URL returned error: 413
fatal: the remote end hung up unexpectedly
fatal: the remote end hung up unexpectedly
Everything up-to-date

Then he told me that he had tried several methods, but none of them worked. The following list of his Baidu out of the scheme

Change the size of the local Git PostBuffer 

git config --global http.postbuffer 524288000

Plan 2: Modify the project. Git /config file and add the following contents 

[http]  
    postBuffer = 524288000

Scheme 3: Increase the Maximum Attachment Size (MB) and Maximum Push Size (MB) with the Account and Limit of the management Account in GitLab

Can refer to this link https://blog.csdn.net/techfield/article/details/70198077 as junior partner not administrator, behind I tried it, it doesn’t work

The problem’s analyse

1. First look at the problems thrown by git push

error: RPC failed; HTTP 413 curl 22 The requested URL returned error: 413

The only information available to us is probably the status code 413, so we can start with that

This status code means

413 Request Entity Too Large

The server refuses to process the current request because the size of the entity submitted by the request is larger than the server is willing or able to process. In this case, the server can close the connection to prevent the client from sending the request further.

Note: check the HTTP status code information, can be refer to by https://www.php.cn/web/web-http.html

From the meaning of the status code, we can conclude that the uploaded code may be too large. So I asked my friend to look at the amount of code he uploaded, and, boy, it’s 4,50 megabytes

2. Solutions

Plan 1: Upload the code in batches, not all at once

My friend solved the problem according to this plan, but he said it was troublesome, because it was impossible to upload the code in batches every time, because the efficiency of submitting the code was very low

Plan 2: Increase the size of HTTP uploads

The solution is to set the postBuffer in the first place, but the problem is that it doesn’t work. Later, I wondered if it was because of the configuration of the domain name, so I used the Intranet IP way to push the code directly, and the result was actually OK.

Then I went to Ping Gitlab domain name, and found that the IP was not Gitlab’s internal network IP, of course, it could be the external network IP, so I pinged the IP through Baidu, shows that the IP is a local area network.

Then it’s natural to wonder if the project’s GitLab has an agent configured, and then ask the former colleagues who took the GitLab. Sure enough, he used Nginx as the agent to build this GitLab before, so he derived the third scheme

Scenario 3: Modify the NGINX configuration

Add client_max_body_size to the HTTP Server node as follows

http: { server: { client_max_body_size: 200m; }}

Scenario 4: Submit code using SSH

Configure SSH, you can refer to the following link https://blog.csdn.net/qq_42832446/article/details/105533733

Источник

Ошибка Github Push: ошибка RPC; result = 22, HTTP-код = 413

глупая проблема с Github происходит прямо сейчас. У меня приличное количество изменений (

120 МБ), когда я пытаюсь нажать, вот что происходит:

git config http.postBuffer 524288000 , так что, похоже, проблема не в этом. Что бы это могло быть?

Я понял это. Конечно, я бы сразу после того, как ударил пост!

У меня был набор репо для использования HTTPS-url, я изменил его на SSH-адрес, и все возобновилось, работая безупречно.

Если вы получаете ошибку 413, проблема не связана с git, а с вашим веб-сервером.
Это ваш веб-сервер, который блокирует большие файлы для загрузки.

Решение для nginx

Просто загрузите nginx.conf и добавьте client_max_body_size 50m; (изменив значение в соответствии с вашими потребностями) в блоке http.

Перезагрузите nginx, чтобы принять новый конфиг, выполнив sudo service nginx reload и повторите попытку, чтобы нажать фиксацию поверх http.

Решение для Apache

В httpd.conf добавьте LimitRequestBody 52428800 (изменив значение в соответствии с вашими потребностями) внутри блока . При этом вы можете ограничить запрос всей файловой системы сервера, всего одного виртуального хоста или каталога.

Надеюсь, это поможет.

для изменения удаленного URL (из https → git @…) есть что-то вроде этого

происхождение здесь – это имя моего удаленного (сделать git remote, а то, что выдается, – это ваше происхождение).

У меня была та же проблема, но я использовал обратный прокси.

Поэтому мне пришлось установить

внутри обоих файлов конфигурации:

  • на веб-сервере gitlab nginx (как указано в предыдущих ответах)
  • , но также и на обратном прокси nginx, размещенном на выделенном сервере.

У меня уже был “HTTPS//” в URL git, но он столкнулся с этой ошибкой.

Все, что я делал, это добавить опцию -u с push и она сработала.

git push -u origin master

Для тех, кто использует IIS 7 для размещения конечной точки git http / https :

Вам нужно увеличить uploadReadAheadSize .

Запустить Диспетчер служб IIS

Разверните поле “Сервер”

Выберите сайт, для которого вы хотите внести изменения.

В разделе “Функции” дважды щелкните Configuration Editor

В разделе Section выберите: system.webServer > serverRuntime

Измените раздел uploadReadAheadSize (значение должно быть между 0 и 2147483647 .)

Если вы столкнулись с этой проблемой во время изменения большого размера, выполните команду ниже в терминале.

Смотрите это для более подробной информации.

У меня возникла эта проблема, когда я пытаюсь клонировать репозиторий git на машине Linux.

для меня в Windows работает следующий URL:

тогда как следующий URL-адрес работает на машине Linux и имеет https в URL

https clone of gists терпит неудачу (ssh работает, см. ниже):

Это работает: git clone git@gist.github.com:123456.git

У меня была эта ошибка (ошибка: RPC failed; result = 22, HTTP code = 413), когда я попытался выполнить мою первоначальную фиксацию в новом репозитории BitBucket. Ошибка произошла для меня, потому что у репликации BitBucket была ветвь без мастера. Если вы используете SourceTree, вы можете создать главную ветвь в начале координат, нажав кнопку Git Flow.

Ошибка возникает в ‘libcurl’, который является базовым протоколом для загрузки https. Решение – как-то обновить libcurl.
Чтобы получить более подробную информацию об ошибке, установите GIT_CURL_VERBOSE = 1

Значение ошибки, согласно libcurl doc:
CURLE_HTTP_RETURNED_ERROR (22)

Это возвращается, если для параметра CURLOPT_FAILONERROR установлено значение ИСТИНА, а HTTP-сервер возвращает код ошибки >= 400.

У меня была такая же проблема (в Win XP), я обновил файл libcurl-4.dll в моем каталоге bin Git до версии SSL из http://www.paehl.com/open_source/?download=curl_DLL_ONLY.7z (переименование в libcurl4.dll). Теперь все работает нормально.

Столкнулась с такой же проблемой.
В моем случае это были несовместимые версии GIT для нескольких пользователей, которые обращаются к одному и тому же проекту (pull/push).

только что обновили версию GIT и обновили путь к настройкам студии Android, и она отлично работает для меня.

Git для Windows (1.9.5) с некоторыми проблемами, обновление может помочь.

Столкнулась с одной и той же проблемой, однако она была решена путем очистки хранилища git (очистить невоспроизводимые файлы с помощью “git clean” ).

Нужно изменить удаленный URL на SSH или HTTPS

Надеюсь, это поможет 🙂

Используете ли вы ссылки https вместо ссылок ssh? Поскольку ссылка https ограничена размером загрузки HttpServer (например, Apache, Ngnix), при использовании ssh такого ограничения нет.

Используйте следующий метод для переключения на ссылку ssh.

  1. Откройте терминал.
  2. Переключитесь на рабочий каталог вашего проекта.
  3. Получить имя удаленного хранилища
  1. Измените адрес git на ссылку ssh.

Если вы определите имя удаленного репозитория, перейдите непосредственно к шагу 4. Теперь вы можете успешно выполнить операцию push.

Когда я использовал URL-адрес https для отправки на удаленный мастер, я столкнулся с той же проблемой, я изменил его на адрес SSH, и все возобновило работу без нареканий.

Источник

error: RPC failed; result=22, HTTP code = 413 #461

Comments

gitblit commented Aug 12, 2015

Originally reported on Google Code with ID 165

Reported by haseeb.yousaf@pentaloop.com on 2012-11-16 10:30:05

The text was updated successfully, but these errors were encountered:

gitblit commented Aug 12, 2015

Reported by James.Moger on 2012-11-16 13:01:16

gitblit commented Aug 12, 2015

Reported by haseeb.yousaf@pentaloop.com on 2012-11-16 13:23:08

gitblit commented Aug 12, 2015

Reported by James.Moger on 2012-11-16 19:21:24

gitblit commented Aug 12, 2015

Reported by James.Moger on 2012-11-16 19:22:45

gitblit commented Aug 12, 2015

Reported by haseeb.yousaf@pentaloop.com on 2012-11-17 07:13:31

gitblit commented Aug 12, 2015

Reported by haseeb.yousaf@pentaloop.com on 2012-11-17 07:24:18

gitblit commented Aug 12, 2015

Reported by James.Moger on 2012-11-17 14:11:18

— _Attachment: capture000.png
![capture000.png](https://storage.googleapis.com/google-code-attachments/gitblit/issue-165/comment-7/capture000.png)_

gitblit commented Aug 12, 2015

Reported by James.Moger on 2013-07-17 20:07:02

  • Status changed: CanNotReproduce

gitblit commented Aug 12, 2015

Reported by sudheer.cyberdyne on 2013-11-06 01:50:05

gitblit commented Aug 12, 2015

Reported by James.Moger on 2013-11-06 12:39:16

gitblit commented Aug 12, 2015

Reported by sundayfunday1234@outlook.com on 2013-11-12 15:46:40

milosmns commented Mar 11, 2017

I’ll write this comment on as many places as possible, I’ve just lost an hour trying to figure out what is happening. Even though it might not be related to the stuff you discussed, I’m pretty sure that people stumble upon this link as much as I do, so hopefully some of them will get the solution.

  • Your push data is too big for the server. You can’t send large files over HTTP by default (you could, but it requires server changes). And, of course, you don’t have access to the server.

Switching to SSH

  1. Go to your $projectRoot/.git/ and open the config file
  2. Inside of your config file you should add the marked line

Note that # is the comment delimiter and you don’t have to write it.
This forces the push URL to use the SSH protocol.
3. Save but don’t close

Still having issues? Yeah, that’s because you need a proper SSH certificate (i.e. either generate a new public/private key pair or use the existing ones). That’s easy to find on Google, look for «Generate SSH key».

Configuring Git to use SSH

Now you have the two keys (private & public). Here is what I did to get them correctly configured with my Git client.

Start the SSH agent. Preconditions: (1) Git must be in your path, or cd into the Git/bin directory; (2) You must be able to use the eval command — either use Unix (Linux/Mac) or download Git Bash for Windows and go from there.
To start the SSH agent, run this:
eval $(ssh-agent -s)
You will get something like this as a response:
Agent pid 1996

Add your SSH key so that Git can use it later:
ssh-add your_key_name_here
The output for that will be something like

Note that this was not the .pub (public) key.

Now go to your repository’s website/config (i.e. GitHub, GitLab, BitBucket. ) and search through profile and repository settings — you want to find a button that allows you to upload your other (public) SSH key. If your two keys don’t match, then the push will fail. If that happens, you messed up the SSH generation somehow.

Okay! Last step, finally.
git push
And your output should be something like this (push does not fail):

Hope this helps.

Oh! One more thing. Remember when I told you not to close the .git/config file? Yeah, you might want to comment out the pushurl parameter now — my IDE was unable to use SSH so I reverted to HTTP. When I’m pushing large files, I quickly go to this page and run through the manual again. .

Источник

Git client 413 error Entity Too Large #14

Comments

ghostlevel commented Aug 9, 2018 •

Hi, not sure this is your prefered place for this kind of errors/bugs or if you had prefered i’d send you an email.

After using the Ghost importer I initially tested to git push one of the posts to blot.im with the structure «Posts/YYYY/MM-DD-title» containing one ‘post.md’ + two JPGs, this worked without problem.

(I renamed all the .TXT files from the importer as .MD)

But when trying to git push all my posts (once i cleaned them up a bit) or only a random-ish selection of them i got this error:

Counting objects: 208, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (206/206), done.
error: RPC failed; HTTP 413 curl 22 The requested URL returned error: 413 Request >Entity Too Large
fatal: The remote end hung up unexpectedly 117.00 KiB/s
Writing objects: 100% (208/208), 36.21 MiB | 5.99 MiB/s, done.
Total 208 (delta 0), reused 0 (delta 0)
fatal: The remote end hung up unexpectedly
Everything up-to-date

Given that my archive/posts contains many images, i double-checked there weren’t too many big ones (i remember seeing something about an error related to file sizes), i usually scale them down & better compress them to

1024px etc to avoid full size

5mb JPGs. So i double-checked and each image is way below

The text was updated successfully, but these errors were encountered:

davidmerfield commented Aug 9, 2018

Bugs filed here are great! I believe you are correct, it is probably NGINX limiting this, specifically the client_max_body_size directive in Blot’s configuration.

The issue is probably that 36mb is greater than 8mb. I’m not sure what a sensible client_max_body_size value is. I believe GitHub has a 150mb push limit.

As a work-around for now, if you incrementally add, commit, then push files (never more than 8mb in a single push) I suspect it’ll work. I recognize this is far from ideal though.

Источник

Unable to import repo to gitlab.com by using git-push

Summary

I cloned a mirror of my remote, ran git-lfs-migrate, git-gc, and attempted to push the mirror to gitlab.com multiple times. On each push attempt, I tried different suggestions found online:

  1. increase the http.postBuffer git config var
  2. push in two steps: first push all lfs objects and then push the history
  3. push from a network where the upload speed is a lot better
  4. force git to use http/1.1

All attempts fatal. On each fatal, the error messages were similar, but varied slightly.

http/1.1 recently failed with http 413, indicating some entity was too large. I stuck with the default core.compression (by being unset), I switched back to http2, and am going to do a more aggressive git gc —prune=now —aggressive . This failed with «pack exceeds maximum allowed size».

I’m going to try to run git gc —prune=now —aggressive but with the following config:

I think this will repack each pack to a max size of 256m. Then I’ll try the push again.

Attempted http/2 with core.compression set to 9 (max). That failed. Going to try the same with http/1.1. I tried http/1.1 in the past, but I don’t think I’ve tried it after a core.compression set to 9 and gc. My current config is:

which, if I’m understanding things correctly, the max size of any pack file is 128M. Maximum compression is on. We need to gc the repo first to map git objects to smaller pack files if they’re too big. Http post buffer is sized to support objects of 128M. We’ll use http/1.1. I think that summarizes what I’m going for pretty accurately.

The most recent attempt failed with «error: RPC failed; curl 56 OpenSSL SSL_read: Connection was aborted, errno 10053». I’ll paste the fuller error output down below. I’ll retry with double the http.postBuffer at 256M, which should be more than enough for these packs of no more than 128M.

I keep getting «RPC failed; curl 56 . » error, and since the error message keeps suggesting I increase the http.postBuffer, I’ll go ahead and double it each time I get this same error message. I’m currently attempting 1G, with the rest of the git-config fixed to the same values.

Steps to reproduce

  1. Clone mirror of some remote hosted internally. My mirror ended up being

30 GB. The size of the repo might matter WRT reproducing the behavior. git clone —mirror https://host:port/path/to/src.git

  • Set origin to gitlab.com:
    1. Install LFS: git lfs install
    2. Mess around with toggling some of these config vars, which were recommended by stackoverflow:

    Here are those links that suggest these config vars:

    1. Migrate the repo to support LFS: git lfs migrate import —everything —yes —include=»*.bin,*.bit,*.bmp,*.cab,*.chk,*.dll,*.exe,*.lib,*.nupkg,*.pdb,*.pdf,*.pof,*.rbf,*.rpd,*.sdb,*.sof,*.xls»
    2. Garbage collection: git gc —prune=now
    3. Turn on logging:
    1. The expected result is something along the lines of a «fatal: the remote end hung up unexpectedly», with an «RPC failed» error of some kind. See below.

    Example Project

    The project that I can reproduce this on is an internal/private one. It is also

    30 GB in size. I have not successfully reproduced this behavior on a minimal project.

    What is the current bug behavior?

    On git-push, one of, or similar to.

    I got the «curl 92» error with HTTP/2 and core.compression 9 (max), following an aggressive gc:

    Using http/1.1, I get «something’s too large»:

    Got the following after making sure compression is on, did git gc —prune=now —aggressive , http2

    With HTTP/1.1, pack size no greater than 128M, postBuffer size 128M. Going to double http post buffer to 256M. With the recent gc however, I think I have guaranteed that no pack exceeds 128M.

    What is the expected correct behavior?

    git-push should successfully complete and exit 0

    Relevant logs and/or screenshots

    I’ve redirected the push output and appended each attempt to a

    Источник

    Источник

    Понравилась статья? Поделить с друзьями:
  • Rpc error program not registered
  • Rpc error no cluster leader
  • Rpc error my keenetic
  • Rpc error in moveitem rust
  • Rpc error in doplace rust plugin