Błąd wypychania na Github: błąd RPC; wynik = 22, kod HTTP = 413

132

głupi problem z Githubem trwającym teraz. Mam przyzwoitą ilość zmian (~ 120MB), kiedy próbuję pchać, dzieje się tak:

error: RPC failed; result=22, HTTP code = 413
fatal: The remote end hung up unexpectedly 
fatal: The remote end hung up unexpectedly

Już to zrobiłem

git config http.postBuffer 524288000, więc to nie wydaje się być problemem. Co to mogło być?

git  github  git-tower 
— Sneakyness
źródło
3
Dla przyszłych odwiedzających, jeśli otrzymujesz HTTP code = 0, GitHub nie działa, jak wczoraj.
— StackExchange User
3
Otrzymałem, HTTP code = 0gdy mój serwer proxy się blokował. Mój serwer proxy http działa z github, ale https nie działa w przypadku mojego korporacyjnego serwera proxy. Myślę, że moje proxy HTTPS wymusza NTLM, podczas gdy HTTP akceptuje BASIC. Zmieniłem adres URL pochodzenia repozytorium z https na http i zadziałało. git remote set-url origin http://github.com/GitUserName/GitRepoName.git
— Motes

Odpowiedzi:

213

Jeśli pojawi się błąd 413, problem nie dotyczy git, ale serwera WWW . To Twój serwer sieciowy blokuje duże pliki do przesłania.

Rozwiązanie dla nginx

Wystarczy załadować nginx.confi dodać client_max_body_size 50m;(zmieniając wartość do swoich potrzeb) w bloku http.

Załaduj ponownie nginx, aby zaakceptować nową konfigurację, wykonując sudo service nginx reloadi spróbuj ponownie przesłać zatwierdzenie przez http.

Rozwiązanie dla Apache

W swoim httpd.confdodaniu LimitRequestBody 52428800(zmieniając wartość do swoich potrzeb) wewnątrz <Directory />bloku. Robiąc to, możesz ograniczyć żądanie całego systemu plików serwera, tylko do pojedynczego hosta wirtualnego lub katalogu.

Mam nadzieję, że to pomoże.

— Tinou
źródło
1
50 m nie było dla mnie wystarczające, ale to rozwiązało mój problem! Dzięki!
— Kevin C. Krinke
Musiałem to zrobić również na pośrednim serwerze proxy Nginx.
— jperelli
2
Co jeśli nie używasz Nginx?
— Katianie
jakieś rozwiązanie dla instalacji omnibus gitlab ..? najnowsza wersja 12.1
— shashwat
Po wielu poszukiwaniach, przeklinaniu i płaczu. (w tej kolejności) Odkryłem, że osadzony plik konfiguracyjny znajduje się pod adresem: /var/opt/gitlab/nginx/conf/gitlab-http.conf
— kroolk.
57

Rozgryzłem to!!! Oczywiście zrobiłbym to zaraz po tym, jak wrzuciłem post!

Ustawiłem repozytorium na używanie adresu URL HTTPS, zmieniłem go na adres SSH i wszystko zaczęło działać bez zarzutu.

— Sneakyness
źródło
53
To nie jest powód problemu. To tylko obejście. Chcę wiedzieć, dlaczego nie działa na https.
— Steve Walsh
4
Dla mnie ssh nie wchodzi w grę. Więc jeśli jesteś w tej samej sytuacji @ZincX, zobacz moją odpowiedź powyżej.
— Tinou,
2
To tylko obejście. Odpowiedź Tinou powinna być zaakceptowaną odpowiedzią.
— Ben
1
jak to zmieniłeś?
— Dainius Kreivys
1
Wiele osób prawdopodobnie nie ma dostępu do swojego serwera internetowego, więc te informacje są bardzo cenne!
— Matthew
39

polecenie zmiany zdalnego adresu URL (z https -> git @ ...) wygląda mniej więcej tak

git remote set-url origin git@github.com:GitUserName/GitRepoName.git

origin tutaj to nazwa mojego pilota (zrób git remote i to, co wychodzi, jest twoim pochodzeniem).

— rozumiem
źródło
2
W przypadku bitbucketa (przycisk „Clone”) miałem problem po usunięciu ssh://z niego, ssh://git@<bitbucket-repo>:<port>/dir/to/project.gitwięc bądźcie ostrożni, ludzie!
— Fightlight
10

Miałem ten sam problem, ale korzystałem z odwrotnego proxy.

Więc musiałem ustawić

client_max_body_size 50m;

wewnątrz obu plików konfiguracyjnych:

  • na serwerze WWW gitlab nginx (jak wspomniano w poprzednich odpowiedziach)
  • ale także na zwrotnym proxy Nginx hostowanym na serwerze dedykowanym.
— grimabe
źródło
jakieś rozwiązanie dla instalacji omnibus gitlab ..?
— shashwat
— grimabe
Chciałem podziękować za to rozwiązanie, miałem dokładnie taką konfigurację.
— tjeerdnet
6

Miałem już „HTTPS //” w adresie URL git, ale napotkałem ten błąd.

Wszystko, co zrobiłem, to dodać opcję -u z push i zadziałało.

git push -u origin master

— Jayzcode
źródło
4

Dla tych, którzy używają usług IIS 7 do hostowania git http/ httpspunktu końcowego:

Musisz zwiększyć swój uploadReadAheadSize.

Uruchom Menedżera internetowych usług informacyjnych (IIS)

  1. Rozwiń pole Serwer

  2. Rozwiń Witryny

  3. Wybierz witrynę, dla której chcesz dokonać modyfikacji.

  4. W sekcji Funkcje kliknij dwukrotnie Configuration Editor

  5. Poniżej Sectionwybierz:system.webServer > serverRuntime

  6. Zmodyfikuj uploadReadAheadSizesekcję (wartość musi zawierać się w przedziale od 0do 2147483647).

  7. Kliknij Apply

  8. Uruchom ponownie witrynę

— Markus Mauch
źródło
Aby zrestartować witrynę, wybrałem opcję Domyślna witryna sieci Web i po prawej stronie w obszarze Akcje znajdują się przyciski Zatrzymaj i Start .
— jgoeders
Ta poprawka była nadal wymagana w IIS 10.
— jgoeders
3

Jeśli napotykasz ten problem podczas wypychania zmian w dużym rozmiarze, uruchom poniższe polecenie w terminalu.

git config --global http.postBuffer 157286400

Zobacz to, aby uzyskać więcej informacji.

— witalny
źródło
1

Błąd występuje w „libcurl”, który jest podstawowym protokołem przesyłania za pomocą protokołu HTTPS. Rozwiązaniem jest jakoś zaktualizować libcurl. Aby uzyskać więcej informacji o błędzie, ustaw GIT_CURL_VERBOSE = 1

https://confluence.atlassian.com/pages/viewpage.action?pageId=306348908

Znaczenie błędu, zgodnie z dokumentem libcurl: CURLE_HTTP_RETURNED_ERROR (22)

Wartość ta jest zwracana, jeśli CURLOPT_FAILONERROR ma wartość TRUE, a serwer HTTP zwraca kod błędu> = 400.

http://curl.haxx.se/libcurl/c/libcurl-errors.html

— FractalSpace
źródło
1

Mam ten problem, gdy próbuję sklonować repozytorium git na komputerze z systemem Linux.

następujący adres URL działa dla mnie w systemie Windows 

http://swamy@git.swamy.com/scm/project/swamy-main.git

podczas gdy poniższy adres URL działa na komputerze z systemem Linux i ma https w adresie URL 

https://swamy@git.swamy.com/scm/project/swamy-main.git
— Swamy
źródło
1

Miałem ten błąd ( błąd: RPC nie powiodło się; wynik = 22, kod HTTP = 413 ), kiedy próbowałem przekazać moje początkowe zatwierdzenie do nowego repozytorium BitBucket. Wystąpił błąd, ponieważ repozytorium BitBucket nie miało gałęzi głównej . Jeśli używasz SourceTree , możesz utworzyć gałąź główną w źródle, naciskając przycisk Git Flow .

— Ben
źródło
1

Czy używasz linków https zamiast linków ssh? Ponieważ łącze https jest ograniczone rozmiarem wysyłanego serwera HttpServer (na przykład Apache, Ngnix), nie ma takiego ograniczenia w przypadku korzystania z ssh.

Użyj poniższej metody, aby przełączyć się na łącze ssh.

  1. Otwórz terminal.
  2. Przejdź do katalogu roboczego projektu.
  3. Uzyskaj nazwę zdalnego repozytorium
$ git remote -v
origin  https://github.com/[user_name]/[project_name].git (fetch)
origin  https://github.com/[user_name]/[project_name].git (push)
  1. Zmodyfikuj adres git na łącze ssh.
git remote set-url origin git@github.com:[user_name]/[project_name].git

Jeśli określisz nazwę repozytorium zdalnego, przejdź bezpośrednio do kroku 4. Teraz możesz szczęśliwie wykonać operację wypychania.

— Zhenjie Yan
źródło
0

Klon gists https nie działa (ssh działa, patrz poniżej):

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

To działa: git clone git@gist.github.com:123456.git

— Jean Jordaan
źródło
OP nie pytał o klon, ale o wypychanie.
— Owen Blacker
1
Cóż, OP zapytał o komunikację z githubem. Nie mam jednak pojęcia, dlaczego odpowiedziałem, mówiąc o streszczeniach.
— Jean Jordaan,
Hah, w porządku :)
— Owen Blacker
0

Miałem ten sam problem. W moim przypadku były to niekompatybilne wersje GIT dla wielu użytkowników, którzy uzyskują dostęp do tego samego projektu (pull / push).

właśnie zaktualizowałem wersję GIT i zaktualizowałem ścieżkę w ustawieniach studia Android i dla mnie działa dobrze.

Edytować -

Git dla Windows (1.9.5) ma jakiś problem, aktualizacja tego samego może pomóc.

— Vishal
źródło
0

Napotkano ten sam problem, ale został on rozwiązany przez wyczyszczenie repozytorium git (wyczyść niezatwierdzone pliki za pomocą „git clean”).

— Darpan
źródło
1
kiedy robię git clean, pokazuje ten błąd: fatal: clean.requireForce domyślnie przyjmuje wartość true i nie podano ani opcji -i, -n, ani -f; odmowa czyszczenia
— Chandni
dla @Chandni i każdego, kto napotka ten sam komunikat o błędzie, git pomaga samemu sobie, spróbuj git clean -ina przykład uruchomić w trybie interaktywnym.
— seethrough
@seethrough - Thanks
— Chandni
0

Musisz zmienić zdalny adres URL na ssh lub https

git remote set-url origin git@github.com:laravel/laravel.git

lub

git remote set-url origin https://github.com/laravel/laravel.git

Mam nadzieję, że to pomoże :)

— Vikash
źródło
0

kiedy użyłem adresu URL https do wysłania do zdalnego mastera, napotkałem ten sam problem, zmieniłem go na adres SSH i wszystko zaczęło działać bez zarzutu.

— lvjiujin
źródło
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.