`git clone` command with HTTPS repo fails with early EOF error #13319

Closed Deuchnord closed 3 years ago

Gitea version (or commit ref): 1.12.5
Git version: 2.29.1
Operating system:
- Server: Debian 9 (Stretch)
- Clients: Arch Linux and macOS Catalina
Database (use [x]):
- [x] PostgreSQL
- [ ] MySQL
- [ ] MSSQL
- [ ] SQLite
Can you reproduce the bug at https://try.gitea.io:
- [ ] Yes (provide example URL)
- [x] No

Log gist _(Important note: for some reasons, I have more logs on server-side when running in prod mode than in dev mode :manshrugging:):

Client:

$ git clone https://git.deuchnord.fr/Deuchnord/Hermes
Cloning into 'Hermes'...
remote: Enumerating objects: 183, done.
remote: Counting objects: 100% (183/183), done.
remote: Compressing objects: 100% (67/67), done.
fatal: the remote end hung up unexpectedly
fatal: early EOF
fatal: index-pack failed

Server:

dc logs -f --tail=10 server | grep "Hermes"
server_1  | [Macaron] 2020-10-27 08:05:50: Started GET /Deuchnord/Hermes/info/refs?service=git-upload-pack for 192.168.128.1
server_1  | [Macaron] 2020-10-27 08:05:50: Completed GET /Deuchnord/Hermes/info/refs?service=git-upload-pack 200 OK in 25.484912ms
server_1  | [Macaron] 2020-10-27 08:05:50: Started POST /Deuchnord/Hermes/git-upload-pack for 192.168.128.1
server_1  | [Macaron] 2020-10-27 08:05:50: Completed POST /Deuchnord/Hermes/git-upload-pack 200 OK in 67.977833ms
server_1  | [Macaron] 2020-10-27 08:05:53: Started GET /Deuchnord/Hermes/src/commit/5d699219ff6bcd63cd96ebf5637e7592ec17e66e/aboutdialog.ui?lang=pt-PT for 192.168.128.1

Description

Cloning a repository from my Gitea instance (at https://git.deuchnord.fr) through HTTPS always fails with an early EOF error. This does not happen if cloning through SSH, but this issue blocks my Drone CI jobs. PS: the repository at https://git.deuchnord.fr/Deuchnord/Hermes is public, feel free to use it to reproduce.

We'll need a bit more information:

How are you running Gitea? Systemd? Docker?
Are you using a http proxy? e.g. nginx/apache?
what does your app.ini look like?

The logs you've given above give us almost no information. Have you read https://docs.gitea.io/en-us/logging-configuration/#debugging-problems ?

* How are you running Gitea? Systemd? Docker?

I'm running it with the gitea/gitea Docker image. This is my docker-compose.yml:

version: "3" 

services:
    server:
        image: gitea/gitea:1.12
        environment:
            USER_UID: 1000
            USER_GID: 1000
            DB_TYPE: postgres
            DB_HOST: 'db:5432'
            DB_NAME: gitea
            DB_USER: gitea
            DB_PASSWORD: nope
        restart: always
        volumes:
            - ./data:/data
        ports:
            - "8000:3000"
            - "7999:22"  # This is used to replace the default 22 port, which is already used by SSH on the host machine.
        depends_on:
            - db
    db: 
        image: postgres:9.6
        restart: always
        environment:
            POSTGRES_USER: gitea
            POSTGRES_PASSWORD: nope
            POSTGRES_DB: gitea
        volumes:
            - ./postgres:/var/lib/postgresql/data

* Are you using a http proxy? e.g. nginx/apache?

Yes, here is the configuration:

server {
        server_name git.deuchnord.fr;
        location / {
                proxy_pass http://127.0.0.1:8000;
        }

        error_log /var/log/nginx/gitea_error.log;
        access_log /var/log/nginx/gitea_access.log;

    listen 443 ssl http2; # managed by Certbot
    ssl_certificate /etc/letsencrypt/live/git.deuchnord.fr/fullchain.pem; # managed by Certbot
    ssl_certificate_key /etc/letsencrypt/live/git.deuchnord.fr/privkey.pem; # managed by Certbot
    include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot
}   

server {
    if ($host = git.deuchnord.fr) {
        return 301 https://$host$request_uri;
    } # managed by Certbot

        server_name git.deuchnord.fr;
    listen 80;
    return 404; # managed by Certbot
}

* what does your app.ini look like?

Here is my app.ini: https://gist.github.com/Deuchnord/1cb6b4992109c2b2f41295515cfcb65c

The logs you've given above give us almost no information. Have you read https://docs.gitea.io/en-us/logging-configuration/#debugging-problems ?

I'm sorry, I didn't see this particular page. After changing the configuration, I get this on clone:

server_1  | 2020/10/28 08:06:21 Started GET /Deuchnord/Hermes.git/info/refs?service=git-upload-pack for 192.168.128.1
server_1  | 2020/10/28 08:06:21 ...s/context/context.go:330:func1() [D] Session ID: 5450164b5a5b1600
server_1  | 2020/10/28 08:06:21 ...s/context/context.go:330:func1() [D] Session ID: 5450164b5a5b1600
server_1  | 2020/10/28 08:06:21 ...s/context/context.go:331:func1() [D] CSRF Token: kHukBoeD9kA_sZ73tVgfs0ttvFw6MTYwMzg3MjM4MTIwMzY2MzczOQ
server_1  | 2020/10/28 08:06:21 ...s/context/context.go:331:func1() [D] CSRF Token: kHukBoeD9kA_sZ73tVgfs0ttvFw6MTYwMzg3MjM4MTIwMzY2MzczOQ
server_1  | [git-module] /data/git/repositories/deuchnord/hermes.git: /usr/bin/git -c credential.helper= -c protocol.version=2 -c filter.lfs.required= -c filter.lfs.smudge= -c filter.lfs.clean= upload-pack --stateless-rpc --advertise-refs .
server_1  | [git-module] stdout:
server_1  | 00fab6de83675cfec2823392400f7598d39abb1bb7ad HEADmulti_ack thin-pack side-band side-band-64k ofs-delta shallow deepen-since deepen-not deepen-relative no-progress include-tag multi_ack_detailed no-done symref=HEAD:refs/heads/master agent=git/2.24.3
server_1  | 003c5d699219ff6bcd63cd96ebf5637e7592ec17e66e refs/heads/dev
server_1  | 003fb6de83675cfec2823392400f7598d39abb1bb7ad refs/heads/master
server_1  | 003ba5090d4709efc3902e6e70dc42c8be8e98910885 refs/tags/0.7
server_1  | 003cb6de83675cfec2823392400f7598d39abb1bb7ad refs/tags/v0.7
server_1  | 003eb6de83675cfec2823392400f7598d39abb1bb7ad refs/tags/v0.7.1
server_1  | 0000
server_1  | 2020/10/28 08:06:21 Completed GET /deuchnord/hermes.git/info/refs?service=git-upload-pack 200 OK in 29.553589ms
server_1  | 2020/10/28 08:06:21 ...s/context/context.go:330:func1() [D] Session ID: 2b81c69a2e3bdb9a
server_1  | 2020/10/28 08:06:21 ...s/context/context.go:330:func1() [D] Session ID: 2b81c69a2e3bdb9a
server_1  | 2020/10/28 08:06:21 ...s/context/context.go:331:func1() [D] CSRF Token: NNCS5M78-OC6YPWjyfAVahts99g6MTYwMzg3MjM4MTI1NjM2NTQ0Ng
server_1  | 2020/10/28 08:06:21 ...s/context/context.go:331:func1() [D] CSRF Token: NNCS5M78-OC6YPWjyfAVahts99g6MTYwMzg3MjM4MTI1NjM2NTQ0Ng
server_1  | 2020/10/28 08:06:21 Started POST /Deuchnord/Hermes.git/git-upload-pack for 192.168.128.1
server_1  | 2020/10/28 08:06:21 Completed POST /deuchnord/hermes.git/git-upload-pack 200 OK in 72.772493ms
server_1  | 2020/10/28 08:06:21 routers/repo/http.go:571:serviceRPC() [E] Fail to serve RPC(upload-pack): signal: broken pipe - 
server_1  | 2020/10/28 08:06:21 routers/repo/http.go:571:serviceRPC() [E] Fail to serve RPC(upload-pack): signal: broken pipe -

This implies that the problem is happening before even the hooks are run. Is it possible that your proxy is terminating the connection because it is sending too large a request?

You're right! That was NGINX's fault!

For the prosperity, adding proxy_buffering off; instruction to the server configuration does the job.

Thank you :heart:

go-gitea / gitea

`git clone` command with HTTPS repo fails with early EOF error #13319

Description