gitea: Unexpected connection loss when cloning via https with slow bandwidth

  • Gitea version (or commit ref): lastest 1.14 and latest main
  • Git version: 2.29
  • Operating system: Debian 10
  • Database (use [x]):
    • PostgreSQL
    • MySQL
    • MSSQL
    • SQLite
  • Can you reproduce the bug at https://try.gitea.io:
    • Yes (provide example URL)
    • No

Description

When cloning a repository with slow bandwidth over https, gitea seems to timeout. We noticed that because F-Droid fails to checkout repositories from codeberg.org, there is also a issue on Codeberg here: https://codeberg.org/Codeberg/Community/issues/461.

This seems to affect try.gitea.io also. Timeouts seem to happen after a few minutes, but not always after the same time. We tried to increase git.timeout values on our test instance also, also accessed port 3000 directly without reverse proxy, without any effect.

$ sudo wondershaper enp0s31f6 4000 4000 # somehow values do not really matter, anything between 500-4000 had the same effect
$ time git clone https://try.gitea.io/ashi/Gadgetbridge
Klone nach 'Gadgetbridge' ...
remote: Enumerating objects: 92096, done.
remote: Counting objects: 100% (92096/92096), done.
remote: Compressing objects: 100% (22562/22562), done.
error: 5767 Bytes des Bodys werden noch erwartet | 12.00 KiB/s
fetch-pack: unexpected disconnect while reading sideband packet
fatal: zu frühes Dateiende
fatal: fetch-pack: ungültige index-pack Ausgabe

real    1m31,925s
user    0m0,005s
sys     0m0,025s

About this issue

  • Original URL
  • State: closed
  • Created 3 years ago
  • Reactions: 2
  • Comments: 23 (23 by maintainers)

Commits related to this issue

Most upvoted comments

I think it’s all similar as I don’t think we set the keep alive header on those either so it’s worth checking if the above suggestion solves things.

If it does then we can add in the keep alive command elsewhere or everywhere.

If it doesn’t then at least we know it’s not that.