Lỗi đẩy Github: RPC không thành công; kết quả = 22, mã HTTP = 413

vấn đề ngu ngốc với Github đang diễn ra ngay bây giờ. Tôi có một lượng thay đổi khá lớn (kích thước ~ 120 MB), khi tôi cố gắng đẩy, đây là điều xảy ra:

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

Tôi đã làm xong

git config http.postBuffer 524288000, do đó dường như không phải là vấn đề. Nó có thể là gì?

Nếu bạn gặp lỗi 413, thì vấn đề không nằm ở git mà là với máy chủ web của bạn . Đó là máy chủ web của bạn đang chặn các tệp tải lên lớn.

Giải pháp cho nginx

Chỉ cần tải của bạn nginx.confvà thêm client_max_body_size 50m;(thay đổi giá trị theo nhu cầu của bạn) trong khối http.

Tải lại nginx để chấp nhận cấu hình mới bằng cách thực thi sudo service nginx reloadvà thử lại để đẩy cam kết của bạn qua http.

Giải pháp cho Apache

Trong httpd.confphần thêm của bạn LimitRequestBody 52428800(thay đổi giá trị theo nhu cầu của bạn) trong một <Directory />khối. Làm điều này bạn có thể giới hạn yêu cầu của toàn bộ hệ thống tập tin máy chủ, chỉ một Máy chủ ảo duy nhất hoặc một thư mục.

Tôi hi vọng cái này giúp được.

Tôi đã hiểu rồi!!! Tất nhiên tôi sẽ ngay sau khi tôi nhấn bài!

Tôi đã cài đặt repo để sử dụng url HTTPS, tôi đã thay đổi nó thành địa chỉ SSH và mọi thứ hoạt động trở lại hoàn hảo.

lệnh thay đổi url từ xa (từ https -> git @ ...) là một cái gì đó như thế này

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

nguồn gốc ở đây là tên của điều khiển từ xa của tôi (làm git từ xa và những gì đi ra là nguồn gốc của bạn).

Tôi đã có cùng một vấn đề nhưng tôi đã sử dụng một proxy ngược.

Vì vậy tôi phải đặt

client_max_body_size 50m; 

bên trong cả hai tập tin cấu hình:

• trên máy chủ web gitlab nginx (như đã nói bên trong các câu trả lời trước)
• mà còn trên proxy ngược nginx được lưu trữ trên máy chủ chuyên dụng.

Tôi đã có "HTTPS //" trong URL git chưa gặp phải lỗi này.

Tất cả những gì tôi đã làm là thêm tùy chọn -u bằng cách đẩy và nó đã hoạt động.

git push -u origin master

Đối với những người sử dụng IIS 7 để lưu trữ git http/ httpsendpoint:

Bạn cần phải tăng của bạn uploadReadAheadSize.

Khởi chạy Trình quản lý dịch vụ thông tin Internet (IIS)

1. Mở rộng trường Máy chủ

2. Mở rộng trang web

3. Chọn trang web bạn muốn thực hiện sửa đổi.

4. Trong phần Tính năng, nhấp đúp Configuration Editor

5. Theo Sectionlựa chọn:system.webServer > serverRuntime

6. Sửa đổi uploadReadAheadSizephần (Giá trị phải nằm giữa 0và 2147483647.)

7. Nhấp chuột Apply

8. Khởi động lại trang web

Nếu bạn đang phải đối mặt với vấn đề này trong khi đẩy các thay đổi ở kích thước lớn thì hãy chạy bên dưới lệnh trong terminal.

git config --global http.postBuffer 157286400

Xem điều này để biết thêm chi tiết.

Lỗi xảy ra trong 'libcurl', đây là giao thức cơ bản để tải lên https. Giải pháp là bằng cách nào đó cập nhật libcurl. Để biết thêm chi tiết về lỗi, đặt GIT_CURL_VERBOSE = 1

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

Ý nghĩa của lỗi, theo tài liệu libcurl: CURLE_HTTP_RETURNED_ERROR (22)

Điều này được trả về nếu CURLOPT_FAILONERROR được đặt TRUE và máy chủ HTTP trả về mã lỗi> = 400.

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

Tôi gặp vấn đề này khi tôi cố gắng sao chép một git repo trong máy Linux.

URL sau đang hoạt động với tôi trong windows

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

trong khi URL sau hoạt động trong máy Linux và URL có URL trong URL

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

Tôi đã gặp lỗi này ( lỗi: RPC không thành công; result = 22, mã HTTP = 413 ) khi tôi cố gắng đẩy cam kết ban đầu của mình sang kho lưu trữ BitBucket mới. Lỗi xảy ra với tôi vì repo BitBucket không có chi nhánh chính. Nếu bạn đang sử dụng SourceTree, bạn có thể tạo một nhánh chính trên điểm gốc bằng cách nhấn nút Git Flow .

Bạn có sử dụng liên kết https thay vì liên kết ssh không? Vì liên kết https bị giới hạn bởi kích thước tải lên của HTTPServer (như Apache, Ngnix), nên không có hạn chế nào như vậy khi sử dụng ssh.

Sử dụng phương pháp sau để chuyển sang liên kết ssh.

1. Mở thiết bị đầu cuối.
2. Chuyển sang thư mục làm việc của dự án của bạn.
3. Lấy tên của kho lưu trữ từ xa

$ git remote -v
origin  https://github.com/[user_name]/[project_name].git (fetch)
origin  https://github.com/[user_name]/[project_name].git (push)

4. Sửa đổi địa chỉ git thành liên kết ssh.

git remote set-url origin git@github.com:[user_name]/[project_name].git

Nếu bạn xác định tên kho lưu trữ từ xa, hãy chuyển trực tiếp đến bước 4. Bây giờ, bạn có thể thực hiện thao tác đẩy một cách vui vẻ.

Tôi gặp vấn đề tương tự (trên Win XP), tôi đã cập nhật tệp libcurl-4.dll trong thư mục Git bin của mình thành phiên bản SSL từ http://www.paehl.com/open_source/?doad=curl_DLL_ONLY.7z (đổi tên để libcurl4.dll). Tất cả đều hoạt động tốt.

Bản sao https không thành công (ssh hoạt động, xem bên dưới):

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

Những công việc này: git clone git@gist.github.com:123456.git

Đã phải đối mặt với cùng một vấn đề. Trong trường hợp của tôi, đó là các phiên bản GIT không tương thích trên nhiều người dùng đang truy cập (kéo / đẩy) cùng một dự án.

vừa cập nhật phiên bản GIT và cập nhật đường dẫn trên cài đặt studio Android và nó hoạt động tốt với tôi.

Biên tập -

Git cho Windows (1.9.5) có một số vấn đề, cập nhật tương tự có thể giúp ích.

Đã đối mặt với cùng một vấn đề tuy nhiên nó đã được giải quyết bằng cách dọn sạch kho git (Làm sạch các tệp không bị theo dõi bằng cách sử dụng "git clean").

Cần thay đổi url từ xa thành ssh hoặc https

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

hoặc là

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

Hy vọng, điều này sẽ giúp :)

Khi tôi sử dụng url https để chuyển sang chủ từ xa, tôi đã gặp một vấn đề tương tự, tôi đã thay đổi nó thành địa chỉ SSH và mọi thứ hoạt động trở lại hoàn hảo.