Large uploads fail in web client #13009

New Issue

GiteaMirror · 2025-11-02T10:27:35-06:00

GiteaMirror commented

2025-11-02 10:27:35 -06:00

Originally created by @exodrifter on GitHub (May 18, 2024).

Description

I'm trying to upload large release binaries (~300MB) to a tagged release Gitea.

The following curl request works and attaches the upload to the release as expected:

curl -vv -X POST -H "Authorization: token $key" "https://$url/api/v1/repos/user/repository/releases/99/assets?name=linux.zip" -F "attachment=@linux.zip"

However, uploading the same attachment through the web interface will hang when the upload progress bar fills up. In my case, Gitea is running in a Docker container behind nginx, so eventually nginx times out. Gitea reports the nginx response as an error and the upload fails to be attached to the release.

I tried to test what would happen if I did the same upload on try.gitea.io but it appears to be down at the moment. I'll try to update this issue later when I'm able to test it there. Unfortunately, I couldn't figure out how to run my Gitea without nginx, since logging in doesn't seem to work.

I found an issue that might be related (#11906), but the fix for it appears to still exist.

Gitea Version

1.21.11

Can you reproduce the bug on the Gitea demo site?

No

Log Gist

https://gist.github.com/exodrifter/2ee2aee15835ea0e4e8f7e007c89b0af

Screenshots

Here's what the web interface looks like when the upload fails:

The error in plaintext:

<html> <head><title>504 Gateway Time-out</title></head> <body> <center><h1>504 Gateway Time-out</h1></center> <hr><center>nginx</center> </body> </html>

Git Version

2.34.1

Operating System

Ubuntu 22.04.4 LTS

How are you running Gitea?

We are running Gitea from docker, which is behind an nginx reverse proxy which is being run in a SWAG container.

Database

PostgreSQL

Originally created by @exodrifter on GitHub (May 18, 2024). ### Description I'm trying to upload large release binaries (~300MB) to a tagged release Gitea. The following curl request works and attaches the upload to the release as expected: ```sh curl -vv -X POST -H "Authorization: token $key" "https://$url/api/v1/repos/user/repository/releases/99/assets?name=linux.zip" -F "attachment=@linux.zip" ``` However, uploading the same attachment through the web interface will hang when the upload progress bar fills up. In my case, Gitea is running in a Docker container behind nginx, so eventually nginx times out. Gitea reports the nginx response as an error and the upload fails to be attached to the release. I tried to test what would happen if I did the same upload on try.gitea.io but it appears to be down at the moment. I'll try to update this issue later when I'm able to test it there. Unfortunately, I couldn't figure out how to run my Gitea without nginx, since logging in doesn't seem to work. I found an issue that might be related (#11906), but the fix for it [appears to still exist](https://github.com/silverwind/gitea/blob/v1.21.11/web_src/js/features/common-global.js#L219). ### Gitea Version 1.21.11 ### Can you reproduce the bug on the Gitea demo site? No ### Log Gist https://gist.github.com/exodrifter/2ee2aee15835ea0e4e8f7e007c89b0af ### Screenshots Here's what the web interface looks like when the upload fails: ![](https://github.com/go-gitea/gitea/assets/1592386/2ff33759-3b2d-4a82-8bfc-a38d1bf17db3) The error in plaintext: ``` <html> <head><title>504 Gateway Time-out</title></head> <body> <center><h1>504 Gateway Time-out</h1></center> <hr><center>nginx</center> </body> </html> ``` ### Git Version 2.34.1 ### Operating System Ubuntu 22.04.4 LTS ### How are you running Gitea? We are running Gitea from docker, which is behind an nginx reverse proxy which is being run in a SWAG container. ### Database PostgreSQL

GiteaMirror added the issue/needs-feedback label 2025-11-02 10:27:35 -06:00

GiteaMirror closed this issue

2025-11-02 10:27:36 -06:00

GiteaMirror commented

2025-11-02 10:27:36 -06:00

@eeyrjmr commented on GitHub (May 18, 2024):

What is your nginx setting with respect to payload?

@eeyrjmr commented on GitHub (May 18, 2024): What is your nginx setting with respect to payload?

GiteaMirror commented

2025-11-02 10:27:36 -06:00

@KN4CK3R commented on GitHub (May 19, 2024):

Check your client_max_body_size setting in nginx.

@KN4CK3R commented on GitHub (May 19, 2024): Check your `client_max_body_size` setting in nginx.

GiteaMirror commented

2025-11-02 10:27:37 -06:00

@exodrifter commented on GitHub (May 20, 2024):

client_max_body_size is 0, which I believe disables checking of the client request body size.

As an aside, I tried testing this on try.gitea.io again, but trying to register an account returns a 500. I'll try again a different day.

@exodrifter commented on GitHub (May 20, 2024): `client_max_body_size` is `0`, which I believe [disables checking of the client request body size](https://nginx.org/en/docs/http/ngx_http_core_module.html#client_max_body_size). As an aside, I tried testing this on try.gitea.io again, but trying to register an account returns a 500. I'll try again a different day.

GiteaMirror commented

2025-11-02 10:27:37 -06:00

@wxiaoguang commented on GitHub (May 27, 2024):

There are some guesses for this problem:

The uploading on nginx side timeouts (eg: improper timeout setting, laggy network, browser proxy, etc)
The uploading on Gitea side timeouts

For the first case, you could try to double-check your config/environment.

For the second case, could you provide a reproducible setup with detailed steps? eg: a docker compose file, and the steps to reproduce. If it could be reproduced on a developer's machine, then it could be fixed soon.

@wxiaoguang commented on GitHub (May 27, 2024): There are some guesses for this problem: 1. The uploading on nginx side timeouts (eg: improper timeout setting, laggy network, browser proxy, etc) 2. The uploading on Gitea side timeouts For the first case, you could try to double-check your config/environment. For the second case, could you provide a reproducible setup with detailed steps? eg: a docker compose file, and the steps to reproduce. If it could be reproduced on a developer's machine, then it could be fixed soon.

GiteaMirror commented

2025-11-02 10:27:38 -06:00

@exodrifter commented on GitHub (May 27, 2024):

I am planning on putting aside some time in two weeks to see if I can create a reproducible setup.

@exodrifter commented on GitHub (May 27, 2024): I am planning on putting aside some time in two weeks to see if I can create a reproducible setup.

GiteaMirror commented

2025-11-02 10:27:38 -06:00

@exodrifter commented on GitHub (Jun 8, 2024):

I was able to test this locally with a docker installation on 1.21.11 as well as on the demo site (which is on 1.23.0+dev-197-gab1948d4a3), and was unable to reproduce it.

I mistakenly assumed that if it worked with cURL that it would be a problem with Gitea, but it is clear to me now that is an issue with how the forward proxy is configured.

@exodrifter commented on GitHub (Jun 8, 2024): I was able to test this locally with a docker installation on 1.21.11 as well as on the demo site (which is on 1.23.0+dev-197-gab1948d4a3), and was unable to reproduce it. I mistakenly assumed that if it worked with cURL that it would be a problem with Gitea, but it is clear to me now that is an issue with how the forward proxy is configured.

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/gitea#13009