github-starred/gitea
2
0
Fork 0
mirror of https://github.com/go-gitea/gitea.git synced 2026-03-12 02:24:21 -05:00
Code Issues 2.6k Packages Projects Releases 100 Wiki Activity

Markdown links started with / broken in 1.23 #13991

New Issue
Closed
opened 2025-11-02 10:59:25 -06:00 by GiteaMirror · 14 comments
GiteaMirror commented 2025-11-02 10:59:25 -06:00
Owner
Copy Link

Originally created by @didim99 on GitHub (Jan 14, 2025).

Description

If you paste a link tag in any place (MD files, issues, comments) started with leading / (without domain) it don't works anymore in 1.23. I'm not sure about 1.22.5 or 1.22.6 but for 1.22.4 or older version this kind of links works perfectly: parsed as absolute URL for whole Gitea instance (domain). For now these liks are parsed as relative to current repository.

[works](https://yourdomain.com:9915/org/repo/readme#section)
[not works](/org/repo/readme#section) <-- works fine in 1.22.4

For example, if you want to link other repo now you need to specify full URL, including domain and port (if customized). In case of transfer Gitea instance to another domain/port it seems to be better to use absolute URLs without domain.

This change broken all our documentation system and old conversation in issues, please, fix it!

Gitea Version

1.23.1

Can you reproduce the bug on the Gitea demo site?

Yes
MD: https://demo.gitea.com/didim99/test-2/src/branch/master/readme.md
Issues: https://demo.gitea.com/didim99/test/issues/1#issue-798

Log Gist

No response

Screenshots

No response

Git Version

Not matters

Operating System

Not matters

How are you running Gitea?

Official install script (updated from 1.22.6)

Database

MySQL/MariaDB

Originally created by @didim99 on GitHub (Jan 14, 2025). ### Description If you paste a link tag in any place (MD files, issues, comments) started with leading `/` (without domain) it don't works anymore in 1.23. I'm not sure about 1.22.5 or 1.22.6 but for 1.22.4 or older version this kind of links works perfectly: parsed as **absolute URL for whole Gitea instance (domain)**. For now these liks are parsed as **relative to current repository**. ```markdown [works](https://yourdomain.com:9915/org/repo/readme#section) [not works](/org/repo/readme#section) <-- works fine in 1.22.4 ``` For example, if you want to link other repo now you need to specify full URL, including domain and port (if customized). In case of transfer Gitea instance to another domain/port it seems to be better to use absolute URLs without domain. This change broken all our documentation system and old conversation in issues, please, fix it! ### Gitea Version 1.23.1 ### Can you reproduce the bug on the Gitea demo site? Yes MD: https://demo.gitea.com/didim99/test-2/src/branch/master/readme.md Issues: https://demo.gitea.com/didim99/test/issues/1#issue-798 ### Log Gist _No response_ ### Screenshots _No response_ ### Git Version Not matters ### Operating System Not matters ### How are you running Gitea? Official install script (updated from 1.22.6) ### Database MySQL/MariaDB
GiteaMirror commented 2025-11-02 10:59:26 -06:00
Author
Owner
Copy Link

@TheFox0x7 commented on GitHub (Jan 14, 2025):

@wxiaoguang FYI since you refactored that part.

I think current behavior is more correct and mirroring github one. Though it wasn't marked as a breaking change.

@TheFox0x7 commented on GitHub (Jan 14, 2025): @wxiaoguang FYI since you refactored that part. I think current behavior is more correct and [mirroring github one](https://github.blog/news-insights/product-news/relative-links-in-markup-files/). Though it wasn't marked as a breaking change.
GiteaMirror commented 2025-11-02 10:59:26 -06:00
Author
Owner
Copy Link

@didim99 commented on GitHub (Jan 14, 2025):

more correct and mirroring github one.

@TheFox0x7 I read this github blog post and related documentation page and can't find any information about links with leading / character. Nothing like "absolute links starting with / should not work". And in HTML standard that kind of URLs is correct.

Okay, relative links without leading / works as before (including ones that contains .. sequence), sounds really like "mirroring github", but there is nothing about leading /. It worked before for a years (at least since mid 2022) and don't works now. So I think it's a bug.

@didim99 commented on GitHub (Jan 14, 2025): > more correct and [mirroring github one](https://github.blog/news-insights/product-news/relative-links-in-markup-files/). @TheFox0x7 I read this github blog post and related documentation page and can't find any information about links with leading `/` character. Nothing like "absolute links starting with `/` should not work". And in HTML standard that kind of URLs is correct. Okay, relative links **without** leading `/` works as before (including ones that contains `..` sequence), sounds really like "mirroring github", but there is nothing about leading `/`. It worked before for a years (at least since mid 2022) and don't works now. So I think it's a bug.
GiteaMirror commented 2025-11-02 10:59:26 -06:00
Author
Owner
Copy Link

@TheFox0x7 commented on GitHub (Jan 14, 2025):

Fair enough, I missed that there's no / in front in that github document. My apologies.
I'm not saying it's not a bug, it is a breaking change which went unannounced so it might as well be a bug/regression.
I did test relative links on github and it treats relative and absolute paths the same, see: https://github.com/TheFox0x7/repro/blob/main/linker.md

What I gather is that you want the /* links to not include the base repository like in the test here:
https://github.com/go-gitea/gitea/blob/main/modules/markup/render_link_test.go#L21
/a being base repository, b being current path in the repository (I'm guessing), and /c being the link from the markup content, which should resolve to /c instead of /a/c. Correct?

I think changing this line to be just link would cover that, though then the nested absolute path test fails and I'm not sure whats the purpose of the /owner/..../owner/.. case.

@TheFox0x7 commented on GitHub (Jan 14, 2025): Fair enough, I missed that there's no `/` in front in that github document. My apologies. I'm not saying it's not a bug, it is a breaking change which went unannounced so it might as well be a bug/regression. I did test relative links on github and it treats relative and absolute paths the same, see: https://github.com/TheFox0x7/repro/blob/main/linker.md What I gather is that you want the `/*` links to not include the base repository like in the test here: https://github.com/go-gitea/gitea/blob/main/modules/markup/render_link_test.go#L21 `/a` being base repository, `b` being current path in the repository (I'm guessing), and `/c` being the link from the markup content, which should resolve to `/c` instead of `/a/c`. Correct? I think changing [this line](https://github.com/go-gitea/gitea/blob/4d399e717dd982fddd2e6e932a98cf757bab9207/modules/markup/render_link.go#L24) to be just link would cover that, though then the nested absolute path test fails and I'm not sure whats the purpose of the `/owner/..../owner/..` case.
GiteaMirror commented 2025-11-02 10:59:26 -06:00
Author
Owner
Copy Link

@wxiaoguang commented on GitHub (Jan 15, 2025):

Yup, it's not broken but just follows other git service's behavior like GitHub.

If you'd like to cross-reference the documents, it needs to use use full link (with https://host/ prefix)

Sorry for the "breaking" change, because there are more stronger requirements for it:

  • Refactor markup render system #32612 (and the issues it has fixed)

[works](https://yourdomain.com:9915/org/repo/readme#section)

ps: I see you are using "readme" for an org, actually there is a feature "profile readme", you could put the readme in {org}/.profile/README.md, then it will be rendered at the org's home page.

@wxiaoguang commented on GitHub (Jan 15, 2025): Yup, it's not broken but just follows other git service's behavior like GitHub. If you'd like to cross-reference the documents, it needs to use use full link (with `https://host/` prefix) Sorry for the "breaking" change, because there are more stronger requirements for it: * Refactor markup render system #32612 (and the issues it has fixed) ---- > `[works](https://yourdomain.com:9915/org/repo/readme#section)` ps: I see you are using "readme" for an org, actually there is a feature "profile readme", you could put the readme in `{org}/.profile/README.md`, then it will be rendered at the org's home page.
GiteaMirror commented 2025-11-02 10:59:26 -06:00
Author
Owner
Copy Link

@didim99 commented on GitHub (Jan 15, 2025):

/a being base repository, b being current path in the repository (I'm guessing), and /c being the link from the markup content, which should resolve to /c instead of /a/c. Correct?

@TheFox0x7 yep, and tests that you mentioned above written in opposite approach.

just follows other git service's behavior like GitHub

@wxiaoguang yes, that's true. But "as others" not always means "better", right? Previous approach was more flexible, allows choice between absolute and relative links using leading /, and for now no more choice.

My proposal is: if this is not too hard to implement, could you make this behaviour configurable via app.ini? Something like ui.use_absolute_links with default false (github-like) but with ability to setting true for backward compatibility for those who used this feature before.

I see you are using "readme" for an org

Readme is just an example. Actually all our cross-repo links (hundreds of them) such as code reference in issues, documentation and so on were written in that manner for portability reason (changing base domain (especially port number) of gitea instance do not broke these links).

@didim99 commented on GitHub (Jan 15, 2025): > `/a` being base repository, `b` being current path in the repository (I'm guessing), and `/c` being the link from the markup content, which should resolve to `/c` instead of `/a/c`. Correct? @TheFox0x7 yep, and tests that you mentioned above written in opposite approach. > just follows other git service's behavior like GitHub @wxiaoguang yes, that's true. But "as others" not always means "better", right? Previous approach was more flexible, allows choice between absolute and relative links using leading /, and for now no more choice. My proposal is: if this is not too hard to implement, could you make this behaviour configurable via app.ini? Something like `ui.use_absolute_links` with default `false` (github-like) but with ability to setting `true` for backward compatibility for those who used this feature before. > I see you are using "readme" for an org Readme is just an example. Actually all our cross-repo links (hundreds of them) such as code reference in issues, documentation and so on were written in that manner for portability reason (changing base domain (especially port number) of gitea instance do not broke these links).
GiteaMirror commented 2025-11-02 10:59:26 -06:00
Author
Owner
Copy Link

@silverwind commented on GitHub (Jan 15, 2025):

This /org/repo/file.md is ambigous with in-repo file links like /file.md which work in both GitHub and Gitea. To really distinguish the two, an new non-ambiguous syntax would be needed, maybe prefix with // or something similar like protocol-relative URLs, but not exactly the same either.

@silverwind commented on GitHub (Jan 15, 2025): This `/org/repo/file.md` is ambigous with in-repo file links like `/file.md` which work in both GitHub and Gitea. To really distinguish the two, an new non-ambiguous syntax would be needed, maybe prefix with `//` or something similar like [protocol-relative URLs](https://en.wikipedia.org/wiki/URL#prurl), but not exactly the same either.
GiteaMirror commented 2025-11-02 10:59:27 -06:00
Author
Owner
Copy Link

@wxiaoguang commented on GitHub (Jan 15, 2025):

maybe prefix with // or something similar

I do not think // could work here, it only omits the "protocol" part.

@wxiaoguang commented on GitHub (Jan 15, 2025): > maybe prefix with `//` or something similar I do not think `//` could work here, it only omits the "protocol" part.
GiteaMirror commented 2025-11-02 10:59:27 -06:00
Author
Owner
Copy Link

@silverwind commented on GitHub (Jan 15, 2025):

Yea we'd need a "origin-relative" or "suburl-relative" URL, but there is no standard for that as far as I'm aware. Maybe /// 😆

@silverwind commented on GitHub (Jan 15, 2025): Yea we'd need a "origin-relative" or "suburl-relative" URL, but there is no standard for that as far as I'm aware. Maybe `///` 😆
GiteaMirror commented 2025-11-02 10:59:27 -06:00
Author
Owner
Copy Link

@wxiaoguang commented on GitHub (Apr 3, 2025):

Yea we'd need a "origin-relative" or "suburl-relative" URL, but there is no standard for that as far as I'm aware. Maybe /// 😆

Or maybe /./path-to-site-root? It won't break existing URLs and is a pretty valid URL

[not works](/./org/repo/readme#section) <-- proposal

@didim99 what do you think?

@wxiaoguang commented on GitHub (Apr 3, 2025): > Yea we'd need a "origin-relative" or "suburl-relative" URL, but there is no standard for that as far as I'm aware. Maybe `///` 😆 Or maybe `/./path-to-site-root`? It won't break existing URLs and is a pretty valid URL ``` [not works](/./org/repo/readme#section) <-- proposal ``` @didim99 what do you think?
GiteaMirror commented 2025-11-02 10:59:27 -06:00
Author
Owner
Copy Link

@didim99 commented on GitHub (Apr 3, 2025):

r maybe /./path-to-site-root?

@wxiaoguang I'm agree, it may be a solution in terms of most possible compatibility.

@didim99 commented on GitHub (Apr 3, 2025): > r maybe `/./path-to-site-root`? @wxiaoguang I'm agree, it may be a solution in terms of most possible compatibility.
GiteaMirror commented 2025-11-02 10:59:27 -06:00
Author
Owner
Copy Link

@wxiaoguang commented on GitHub (Apr 3, 2025):

I am going to make some more improvements to the markdown module (to clean up some legacy problems). For this "relative link" problem, there are some initial ideas in my mind at the moment, let's see how good we can make it:

  • Using a config option: use_absolute_links=true
  • Using a special link path: /./path-to-site-root
  • Using some special names:
    • /@root/path-to-site-root, for example: /@root/AnotherOrg/TheRepo/issues
    • /@owner/a-repo-name, for example: /@owner/AnotherRepo/issues
    • /@repo/a-path-in-repo, for example: /@repo/src/branch/raw/...

The special names seem flexible enough, the only question is that whether it would cause unsolvable conflict in the future.

  • Will it conflict with @ mentioning parser?
    • Maybe use other chars like /$root/.... ?
@wxiaoguang commented on GitHub (Apr 3, 2025): I am going to make some more improvements to the markdown module (to clean up some legacy problems). For this "relative link" problem, there are some initial ideas in my mind at the moment, let's see how good we can make it: * Using a config option: `use_absolute_links=true` * Using a special link path: `/./path-to-site-root` * Using some special names: * `/@root/path-to-site-root`, for example: `/@root/AnotherOrg/TheRepo/issues` * `/@owner/a-repo-name`, for example: `/@owner/AnotherRepo/issues` * `/@repo/a-path-in-repo`, for example: `/@repo/src/branch/raw/...` The special names seem flexible enough, the only question is that whether it would cause unsolvable conflict in the future. * Will it conflict with `@` mentioning parser? * Maybe use other chars like `/$root/....` ?
GiteaMirror commented 2025-11-02 10:59:28 -06:00
Author
Owner
Copy Link

@silverwind commented on GitHub (Apr 3, 2025):

We should only definitely use characters that are forbidden in repo and org names. I think @ is forbidden in both, but good to double-check as I recall gitea is still allowing too much and is not compatible with github regarding allowed repo and org names (see https://github.com/go-gitea/gitea/issues/4150#issuecomment-2142191169 and https://github.com/go-gitea/gitea/issues/4150#issuecomment-2142204117 specifically).

@silverwind commented on GitHub (Apr 3, 2025): We should only definitely use characters that are forbidden in repo and org names. I think `@` is forbidden in both, but good to double-check as I recall gitea is still allowing too much and is not compatible with github regarding allowed repo and org names (see https://github.com/go-gitea/gitea/issues/4150#issuecomment-2142191169 and https://github.com/go-gitea/gitea/issues/4150#issuecomment-2142204117 specifically).
GiteaMirror commented 2025-11-02 10:59:28 -06:00
Author
Owner
Copy Link

@didim99 commented on GitHub (Apr 3, 2025):

@wxiaoguang using special names looks very nice! IMO using @ as marker char is a not best idea because that notation used for mentions, $ (or maybe something else, but for now I not have any suitable proposal) is more preferred in this case.

@didim99 commented on GitHub (Apr 3, 2025): @wxiaoguang using special names looks very nice! IMO using `@` as marker char is a not best idea because that notation used for mentions, `$` (or maybe something else, but for now I not have any suitable proposal) is more preferred in this case.
GiteaMirror commented 2025-11-02 10:59:28 -06:00
Author
Owner
Copy Link

@wxiaoguang commented on GitHub (Apr 4, 2025):

-> Refactor markup render to fix various path problems #34114

The final decision in my mind is "using :"

The reason is:

  • : is a valid URL path character, no need to escape
  • : won't conflict with other designs (@ for mentioning, $ for variable, etc)
@wxiaoguang commented on GitHub (Apr 4, 2025): -> Refactor markup render to fix various path problems #34114 The final decision in my mind is "using `:`" The reason is: * `:` is a valid URL path character, no need to escape * `:` won't conflict with other designs (`@` for mentioning, `$` for variable, etc)
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#13991
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?