Attachment links are not human readable again #5164

New Issue

GiteaMirror · 2025-11-02T06:16:34-06:00

GiteaMirror commented

2025-11-02 06:16:34 -06:00

Originally created by @xoxys on GitHub (Apr 1, 2020).

Gitea version (or commit ref): 1.11.4
Operating system: CentOS 7
Database (use [x]):
- PostgreSQL
- MySQL
- MSSQL
- SQLite

Description

After upgrading to v1.11.3 release attachment links are not human-readable again and now looks like https://gitea.example/attachments/a0023262-7abf-461d-9271-2e9f195ecebc instead of https://gitea.example/xoxys/cups-rpm/releases/download/v.1.0.0.

Originally created by @xoxys on GitHub (Apr 1, 2020). - Gitea version (or commit ref): 1.11.4 - Operating system: CentOS 7 - Database (use `[x]`): - [X] PostgreSQL - [ ] MySQL - [ ] MSSQL - [ ] SQLite ## Description After upgrading to v1.11.3 release attachment links are not human-readable again and now looks like `https://gitea.example/attachments/a0023262-7abf-461d-9271-2e9f195ecebc` instead of `https://gitea.example/xoxys/cups-rpm/releases/download/v.1.0.0`.

GiteaMirror added the topic/ui issue/confirmed labels 2025-11-02 06:16:34 -06:00

GiteaMirror closed this issue

2025-11-02 06:16:35 -06:00

GiteaMirror commented

2025-11-02 06:16:35 -06:00

@jolheiser commented on GitHub (Apr 1, 2020):

The change was in #9529 and this functionality can return once #9534 is fixed.

Until then, the URL pattern still works, it's just no longer exposed on the UI. 🙁

e.g.
https://try.gitea.io/jolheiser/ciw/releases
https://try.gitea.io/jolheiser/ciw/releases/download/test2/simplog.png

@jolheiser commented on GitHub (Apr 1, 2020): The change was in #9529 and this functionality can return once #9534 is fixed. Until then, the URL pattern still works, it's just no longer exposed on the UI. 🙁 e.g. https://try.gitea.io/jolheiser/ciw/releases https://try.gitea.io/jolheiser/ciw/releases/download/test2/simplog.png

GiteaMirror commented

2025-11-02 06:16:35 -06:00

@6543 commented on GitHub (Apr 1, 2020):

@xoxys you still can use the https://gitea.example/xoxys/cups-rpm/releases/download/v.1.0.0

IT STILL works - but it there is a problem with name colision/ same names...
"if #9534 got implemented we can switch back to human redable"

so this is the reason why UI using uuid's at the moment

@6543 commented on GitHub (Apr 1, 2020): @xoxys you still can use the `https://gitea.example/xoxys/cups-rpm/releases/download/v.1.0.0` IT STILL works - but it there is a problem with name colision/ same names... "if #9534 got implemented we can switch back to human redable" so this is the reason why UI using uuid's at the moment

GiteaMirror commented

2025-11-02 06:16:36 -06:00

@xoxys commented on GitHub (Apr 1, 2020):

Ok than I'll still wait

@xoxys commented on GitHub (Apr 1, 2020): Ok than I'll still wait

GiteaMirror commented

2025-11-02 06:16:36 -06:00

@stale[bot] commented on GitHub (May 31, 2020):

This issue has been automatically marked as stale because it has not had recent activity. I am here to help clear issues left open even if solved or waiting for more insight. This issue will be closed if no further activity occurs during the next 2 weeks. If the issue is still valid just add a comment to keep it alive. Thank you for your contributions.

@stale[bot] commented on GitHub (May 31, 2020): This issue has been automatically marked as stale because it has not had recent activity. I am here to help clear issues left open even if solved or waiting for more insight. This issue will be closed if no further activity occurs during the next 2 weeks. If the issue is still valid just add a comment to keep it alive. Thank you for your contributions.

GiteaMirror commented

2025-11-02 06:16:36 -06:00

@xoxys commented on GitHub (May 31, 2020):

Keep until fixed?

@xoxys commented on GitHub (May 31, 2020): Keep until fixed?

GiteaMirror commented

2025-11-02 06:16:36 -06:00

@xoxys commented on GitHub (Nov 5, 2021):

Is there still no fix for it? Even if I can build the readable URLs on my own, it's pretty hard for the "normal" user. I am surprised that I am the only one who is bothered by it 😄

@xoxys commented on GitHub (Nov 5, 2021): Is there still no fix for it? Even if I can build the readable URLs on my own, it's pretty hard for the "normal" user. I am surprised that I am the only one who is bothered by it :smile:

GiteaMirror commented

2025-11-02 06:16:36 -06:00

@xuanswe commented on GitHub (Mar 28, 2022):

I have a related issue with attachment URL. Not sure if I need to create a new ticket or this one will fix it too.

Assuming, I have the gitea configured as http://192.168.1.1:1234.
There's a revert proxy in my local network point to this server: http://gitea.home

If I open a release page http://gitea.home/org/repo/releases, I will have 3 URLs:
Source Code (ZIP) http://gitea.home/org/repo/archive/0.0.1-SNAPSHOT.zip
Source Code (TAR.GZ) http://gitea.home/org/repo/archive/0.0.1-SNAPSHOT.tar.gz
attachment.zip http://192.168.1.1:1234/attachments/a3793480-68ed-48c9-ae70-e57e512383b2

I would expect, the attachment URL use http://gitea.home, same as Source Code URLs.

Note: if I manually enter the URL http://gitea.home/attachments/a3793480-68ed-48c9-ae70-e57e512383b2, it works.

@xuanswe commented on GitHub (Mar 28, 2022): I have a related issue with attachment URL. Not sure if I need to create a new ticket or this one will fix it too. Assuming, I have the gitea configured as http://192.168.1.1:1234. There's a revert proxy in my local network point to this server: http://gitea.home If I open a release page http://gitea.home/org/repo/releases, I will have 3 URLs: Source Code (ZIP) http://gitea.home/org/repo/archive/0.0.1-SNAPSHOT.zip Source Code (TAR.GZ) http://gitea.home/org/repo/archive/0.0.1-SNAPSHOT.tar.gz attachment.zip http://192.168.1.1:1234/attachments/a3793480-68ed-48c9-ae70-e57e512383b2 I would expect, the attachment URL use http://gitea.home, same as Source Code URLs. Note: if I manually enter the URL http://gitea.home/attachments/a3793480-68ed-48c9-ae70-e57e512383b2, it works.

GiteaMirror commented

2025-11-02 06:16:36 -06:00

@reivilibre commented on GitHub (Apr 7, 2022):

I've been finding this inconvenient for tools that wish to be able to download a specific release's binaries for a specific architecture (and it also makes the config files for those much harder to read, since at a glance you can't tell which version is in use).

I had no idea that this was already possible, just 'secret', according to the following scheme (deduced from the messages above):
https://my.gitea/user/project/releases/download/v0.0.1/blahblah-v0.0.1-linux-arm64

@reivilibre commented on GitHub (Apr 7, 2022): I've been finding this inconvenient for tools that wish to be able to download a specific release's binaries for a specific architecture (and it also makes the config files for those much harder to read, since at a glance you can't tell which version is in use). I had no idea that this was already possible, just 'secret', according to the following scheme (deduced from the messages above): `https://my.gitea/user/project/releases/download/v0.0.1/blahblah-v0.0.1-linux-arm64`

GiteaMirror commented

2025-11-02 06:16:37 -06:00

@wxiaoguang commented on GitHub (Apr 7, 2022):

Can we just take the simple fix in https://github.com/go-gitea/gitea/pull/13750 at the moment, and make future PRs for the remaining TODOs? @6543

@wxiaoguang commented on GitHub (Apr 7, 2022): Can we just take the simple fix in https://github.com/go-gitea/gitea/pull/13750 at the moment, and make future PRs for the remaining TODOs? @6543

GiteaMirror commented

2025-11-02 06:16:37 -06:00

@drsybren commented on GitHub (Feb 9, 2023):

I would also welcome more human-readable URLs.

Maybe the URL matching patterns can be altered to accept any name after the UUID? That way a link can be constructed like http://gitea.home/attachments/a3793480-68ed-48c9-ae70-e57e512383b2/original-filename.txt. This ensures that the URL is still unique, but also ensures that doing a wget {url} saves to the correct filename.

Personally this would make my workflow of investigating Blender bug reports a lot easier. What I used to do (before moving to Gitea) was to type wget in a terminal, with the current working directory already set to where I want the file to be, then drag the link from my webbrowser to the terminal (which pastes it after the wget command).

@drsybren commented on GitHub (Feb 9, 2023): I would also welcome more human-readable URLs. Maybe the URL matching patterns can be altered to accept any name after the UUID? That way a link can be constructed like `http://gitea.home/attachments/a3793480-68ed-48c9-ae70-e57e512383b2/original-filename.txt`. This ensures that the URL is still unique, but also ensures that doing a `wget {url}` saves to the correct filename. Personally this would make my workflow of investigating Blender bug reports a lot easier. What I used to do (before moving to Gitea) was to type `wget ` in a terminal, with the current working directory already set to where I want the file to be, then drag the link from my webbrowser to the terminal (which pastes it after the `wget` command).

GiteaMirror referenced this issue

2025-11-02 14:56:08 -06:00

[PR #5165] [MERGED] Set heatmap color range configurable #17674

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#5164