Markdown links with whitespace can no longer be resolved in Wiki #4832

New Issue

GiteaMirror · 2025-11-02T06:04:09-06:00

GiteaMirror commented

2025-11-02 06:04:09 -06:00

Originally created by @proton-ab on GitHub (Feb 10, 2020).

Gitea version (or commit ref): 1.11.0
Git version: -
Operating system: -
Database (use [x]):
- PostgreSQL
- MySQL
- MSSQL
- SQLite
Can you reproduce the bug at https://try.gitea.io:
- Yes (provide example URL)
- No
- Not relevant
Log gist: -

Description

Markdown links to other pages in wiki are no longer resolved if they have whitespace in them.
https://try.gitea.io/3red3x/wikitest/wiki/Home
https://try.gitea.io/3red3x/wikitest/wiki/Development-database-snapshot

Screenshots

Raw link:

On Gitea 1.10.2:

On Gitea 1.11.0:

Originally created by @proton-ab on GitHub (Feb 10, 2020).   - Gitea version (or commit ref): 1.11.0 - Git version: - - Operating system: - - Database (use `[x]`): - [x] PostgreSQL - [x] MySQL - [ ] MSSQL - [ ] SQLite - Can you reproduce the bug at https://try.gitea.io: - [x] Yes (provide example URL) - [ ] No - [ ] Not relevant - Log gist: - ## Description Markdown links to other pages in wiki are no longer resolved if they have whitespace in them. https://try.gitea.io/3red3x/wikitest/wiki/Home https://try.gitea.io/3red3x/wikitest/wiki/Development-database-snapshot ## Screenshots Raw link: ![chrome_2020-02-10_22-59-45](https://user-images.githubusercontent.com/25139420/74194421-81b2cb00-4c59-11ea-80ac-3764c1ec00c6.png) On Gitea 1.10.2: ![chrome_2020-02-10_22-59-34](https://user-images.githubusercontent.com/25139420/74194390-6a73dd80-4c59-11ea-8adc-ccb72d980741.png) On Gitea 1.11.0: ![firefox_2020-02-10_23-00-04](https://user-images.githubusercontent.com/25139420/74194442-8b3c3300-4c59-11ea-9443-397562b81c64.png)

GiteaMirror added the issue/not-a-bug label 2025-11-02 06:04:09 -06:00

GiteaMirror closed this issue

2025-11-02 06:04:09 -06:00

GiteaMirror commented

2025-11-02 06:04:10 -06:00

@heliomcp commented on GitHub (Feb 12, 2020):

I have an identical ticket #10156

In my example I only use 2 markdown pages inside a directory with a space in the name and if we use the link between the to pages Gitea change the stace (%20) to signal +

@heliomcp commented on GitHub (Feb 12, 2020): I have an identical ticket #10156 In my example I only use 2 markdown pages inside a directory with a space in the name and if we use the link between the to pages Gitea change the stace (%20) to signal +

GiteaMirror commented

2025-11-02 06:04:10 -06:00

@proton-ab commented on GitHub (Feb 13, 2020):

That's a different issue - in your case there's improper entities handling when constructing link, but the link does get parsed. This issue tracks case where markdown links are not parsed and constructed at all when they contain space and are not an URL but relative name.

@proton-ab commented on GitHub (Feb 13, 2020): That's a different issue - in your case there's improper entities handling when constructing link, but the link does get parsed. This issue tracks case where markdown links are not parsed and constructed at all when they contain space and are not an URL but relative name.

GiteaMirror commented

2025-11-02 06:04:10 -06:00

@mrsdizzie commented on GitHub (Feb 14, 2020):

FWIW this is intentional as it is not allowed in the commonmark spec:

https://spec.commonmark.org/0.29/#link-destination

a sequence of zero or more characters between an opening < and a closing > that contains no line breaks or unescaped < or > characters, or

a nonempty sequence of characters that does not start with <, does not include ASCII space or control characters, and includes parentheses only if (a) they are backslash-escaped or (b) they are part of a balanced pair of unescaped parentheses. (Implementations may impose limits on parentheses nesting to avoid performance issues, but at least three levels of nesting should be supported.)

And we now use a new markdown library that follows that spec (as a feature).

You can find similar issues for other projects that follow commonmark (or use a library that does). So it's a regression in the sense it used to work when we used a library that didn't follow a standard, but if part of the goal of switching is to follow a standard then I suppose it is intentional now and a breaking change.

As per the spec, you can keep the page names with spaces you just need to enclose the links in <> brackets:

https://spec.commonmark.org/0.29/#example-486

So in your example it would need to look like:

[Development database snapshot](<Development database snapshot>)

@mrsdizzie commented on GitHub (Feb 14, 2020): FWIW this is intentional as it is not allowed in the commonmark spec: https://spec.commonmark.org/0.29/#link-destination >a sequence of zero or more characters between an opening < and a closing > that contains no line breaks or unescaped < or > characters, or > > a nonempty sequence of characters that does not start with <, does not include ASCII space or control characters, and includes parentheses only if (a) they are backslash-escaped or (b) they are part of a balanced pair of unescaped parentheses. (Implementations may impose limits on parentheses nesting to avoid performance issues, but at least three levels of nesting should be supported.) And we now use a new markdown library that follows that spec (as a feature). You can find similar issues for other projects that follow commonmark (or use a library that does). So it's a regression in the sense it used to work when we used a library that didn't follow a standard, but if part of the goal of switching is to follow a standard then I suppose it is intentional now and a breaking change. As per the spec, you can keep the page names with spaces you just need to enclose the links in <> brackets: https://spec.commonmark.org/0.29/#example-486 So in your example it would need to look like: ``` [Development database snapshot](<Development database snapshot>) ```

GiteaMirror commented

2025-11-02 06:04:10 -06:00

@guillep2k commented on GitHub (Feb 19, 2020):

Related: #10291

@guillep2k commented on GitHub (Feb 19, 2020): Related: #10291

GiteaMirror commented

2025-11-02 06:04:11 -06:00

@mrsdizzie commented on GitHub (Feb 19, 2020):

This could probably be closed as a breaking change with switching to a markdown parser that follows a particular spec (which we listed as a reason for switching to it). Comment above is the new "right" way to use short links with spaces according to commonmark

@mrsdizzie commented on GitHub (Feb 19, 2020): This could probably be closed as a breaking change with switching to a markdown parser that follows a particular spec (which we listed as a reason for switching to it). Comment above is the new "right" way to use short links with spaces according to commonmark

GiteaMirror commented

2025-11-02 06:04:11 -06:00

@proton-ab commented on GitHub (Feb 19, 2020):

Agreed, should be documented as breaking change however.

@proton-ab commented on GitHub (Feb 19, 2020): Agreed, should be documented as breaking change however.

GiteaMirror commented

2025-11-02 06:04:11 -06:00

@guillep2k commented on GitHub (Mar 5, 2020):

Closing as this was the expected behavior. Docs will be updated to clarify the case in #10223.

@guillep2k commented on GitHub (Mar 5, 2020): Closing as this was the expected behavior. Docs will be updated to clarify the case in #10223.

GiteaMirror referenced this issue

2025-11-02 13:51:38 -06:00