github-starred/gitea
2
0
Fork 0
mirror of https://github.com/go-gitea/gitea.git synced 2026-03-11 17:46:29 -05:00
Code Issues 2.6k Packages Projects Releases 100 Wiki Activity

Allow to serve (repo-)avatars statically #7344

New Issue
Closed
opened 2025-11-02 07:23:30 -06:00 by GiteaMirror · 6 comments
GiteaMirror commented 2025-11-02 07:23:30 -06:00
Owner
Copy Link

Originally created by @ghost on GitHub (May 16, 2021).

  • Gitea version (or commit ref): 1.13.7
  • Git version: 2.31.1
  • Operating system: Arch Linux
  • Database (use [x]):
    • PostgreSQL
    • MySQL
    • MSSQL
    • SQLite
    • Irrelevant
  • Can you reproduce the bug at https://try.gitea.io:
    • Yes (provide example URL)
    • No
    • Irrelevant
  • Log gist: Irrelevant

Description

Currently, there are issues with data/avatars and data/repo-avatars folders and their files (user:group is set to gitea:gitea, for repo-avatars files, umask is set to restrictive 077), so it is impossible to serve images using caching web server (unless running everything from root user).

Screenshots

Irrelevant

Originally created by @ghost on GitHub (May 16, 2021). <!-- NOTE: If your issue is a security concern, please send an email to security@gitea.io instead of opening a public issue --> <!-- 1. Please speak English, this is the language all maintainers can speak and write. 2. Please ask questions or configuration/deploy problems on our Discord server (https://discord.gg/gitea) or forum (https://discourse.gitea.io). 3. Please take a moment to check that your issue doesn't already exist. 4. Make sure it's not mentioned in the FAQ (https://docs.gitea.io/en-us/faq) 5. Please give all relevant information below for bug reports, because incomplete details will be handled as an invalid report. --> - Gitea version (or commit ref): 1.13.7 - Git version: 2.31.1 - Operating system: Arch Linux <!-- Please include information on whether you built gitea yourself, used one of our downloads or are using some other package --> <!-- Please also tell us how you are running gitea, e.g. if it is being run from docker, a command-line, systemd etc. ---> <!-- If you are using a package or systemd tell us what distribution you are using --> - Database (use `[x]`): - [ ] PostgreSQL - [ ] MySQL - [ ] MSSQL - [ ] SQLite - [x] Irrelevant - Can you reproduce the bug at https://try.gitea.io: - [ ] Yes (provide example URL) - [ ] No - [x] Irrelevant - Log gist: Irrelevant <!-- It really is important to provide pertinent logs --> <!-- Please read https://docs.gitea.io/en-us/logging-configuration/#debugging-problems --> <!-- In addition, if your problem relates to git commands set `RUN_MODE=dev` at the top of app.ini --> ## Description <!-- If using a proxy or a CDN (e.g. CloudFlare) in front of gitea, please disable the proxy/CDN fully and connect to gitea directly to confirm the issue still persists without those services. --> Currently, there are issues with `data/avatars` and `data/repo-avatars` folders and their files (`user:group` is set to `gitea:gitea`, for repo-avatars files, umask is set to restrictive 077), so it is impossible to serve images using caching web server (unless running everything from root user). ## Screenshots <!-- **If this issue involves the Web Interface, please include a screenshot** --> Irrelevant
GiteaMirror commented 2025-11-02 07:23:31 -06:00
Author
Owner
Copy Link

@silverwind commented on GitHub (May 16, 2021):

Avatars should already be cached well using STATIC_CACHE_TIME, why do you want to serve them separately?

@silverwind commented on GitHub (May 16, 2021): Avatars should already be cached well using `STATIC_CACHE_TIME`, why do you want to serve them separately?
GiteaMirror commented 2025-11-02 07:23:31 -06:00
Author
Owner
Copy Link

@ghost commented on GitHub (May 16, 2021):

Avatars should already be cached well using STATIC_CACHE_TIME, why do you want to serve them separately?

I mean sending files from server, not client side caching. Calling gitea embedded webserver for static files is less efficient comparing to sending via nginx.

@ghost commented on GitHub (May 16, 2021): > Avatars should already be cached well using `STATIC_CACHE_TIME`, why do you want to serve them separately? I mean sending files from server, not client side caching. Calling gitea embedded webserver for static files is less efficient comparing to sending via nginx.
GiteaMirror commented 2025-11-02 07:23:31 -06:00
Author
Owner
Copy Link

@silverwind commented on GitHub (May 16, 2021):

Hmm indeed, I think avatars have to come from the gitea webserver currently, so that is a valid concern.

@silverwind commented on GitHub (May 16, 2021): Hmm indeed, I think avatars have to come from the gitea webserver currently, so that is a valid concern.
GiteaMirror commented 2025-11-02 07:23:32 -06:00
Author
Owner
Copy Link

@ghost commented on GitHub (May 16, 2021):

I think avatars have to come from the gitea webserver currently

Why? Avatars are just files, and if they are stored locally, I see no issues with offloading static requests to caching web server. Similar option is already available for static resources like scripts, styles, fonts etc.

@ghost commented on GitHub (May 16, 2021): > I think avatars have to come from the gitea webserver currently Why? Avatars are just files, and if they are stored locally, I see no issues with offloading static requests to caching web server. Similar option is already available for static resources like scripts, styles, fonts etc.
GiteaMirror commented 2025-11-02 07:23:32 -06:00
Author
Owner
Copy Link

@silverwind commented on GitHub (May 16, 2021):

IDK, but I guess we could make them world-readable to allow such configurations.

@silverwind commented on GitHub (May 16, 2021): IDK, but I guess we could make them world-readable to allow such configurations.
GiteaMirror commented 2025-11-02 07:23:32 -06:00
Author
Owner
Copy Link

@techknowlogick commented on GitHub (May 17, 2021):

This is possible currently by using the CDN setting of gitea and pointing it at a host that fetches the files from disk which nginx could do.

@techknowlogick commented on GitHub (May 17, 2021): This is possible currently by using the CDN setting of gitea and pointing it at a host that fetches the files from disk which nginx could do.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
$20
$250
$50
$500
backport/done
💎 Bounty
docs-update-needed
good first issue
hacktoberfest
issue/bounty
issue/confirmed
issue/critical
issue/duplicate
issue/needs-feedback
issue/not-a-bug
issue/regression
issue/stale
issue/workaround
lgtm/need 2
modifies/api
modifies/translation
outdated/backport/v1.18
outdated/theme/markdown
outdated/theme/timetracker
performance/bigrepo
performance/cpu
performance/memory
performance/speed
pr/breaking
proposal/accepted
proposal/rejected
pr/wip
pull-request
Mirrored from GitHub Pull Request
 reviewed/wontfix
💰 Rewarded
skip-changelog
status/blocked
topic/accessibility
topic/api
topic/authentication
topic/build
topic/code-linting
topic/commit-signing
topic/content-rendering
topic/deployment
topic/distribution
topic/federation
topic/gitea-actions
topic/issues
topic/lfs
topic/mobile
topic/moderation
topic/packages
topic/pr
topic/projects
topic/repo
topic/repo-migration
topic/security
topic/theme
topic/ui
topic/ui-interaction
topic/ux
topic/webhooks
topic/wiki
type/bug
type/deprecation
type/docs
type/enhancement
type/feature
type/miscellaneous
type/proposal
type/question
type/refactoring
type/summary
type/testing
type/upstream
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
GiteaMirror ninjasurge
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/gitea#7344
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?