Since updating to our docker based GitLab instance to 14.10.2 all wiki pages that are not at the root of the wiki [1] no longer render and instead show an alert box with the message:
The content for this wiki page failed to load. To fix this error, reload the page.
This applies to existing pages as well as newly created ones. Existing and newly created pages at the wiki root work fine, e.g.
https://gitlab.example.com/example-group/example-wiki/-/wikis/home renders fine, while
https://gitlab.example.com/example-group/example-wiki/-/wikis/subdirectory/testpage does not.
I don’t see anything obvious in the logs, but I’m also not sure what to look for. Any suggestions how to narrow down which component is failing? Thanks!
[1] this is a small, internal setup and we really only use the project wiki of a single project.
2 Likes
Hello. I’ve noticed this problem too. While editing the page, it looks okay and even preview is fine, but link to it does not.
Does any other have this problem too? Thanks in advance for answers.
Edit: version is: v14.10.2-ee
Yes, I’ve had the same problem after upgrading to 14.10.2-ce. I’ve since upgraded to 15.0.0 and the problem remains.
I’ve raised an issue: https://gitlab.com/gitlab-org/gitlab/-/issues/363231
I should add that I see this problem on my production Debian 9 instance, but not on my test instance which runs Debian 11.
Hello, since mid of may, I was also looking for other people meeting this problem: happy to find you here and to see your issue on gitlab.com to follow the topic. As temporary work around in one of my wiki with few pages, I have moved the wiki-pages under the root by creating new pages and copy-pasting the markdown content, but I cannot do that on wikis with too much pages. Expecting a coming bug-fix soon ! gitlab-ce 14.10.3-ce.0 on ubuntu 20.04 LTS.
In my case rendering stopped because of introduction of API use.
Due to infrastructure proxy escaped url encoded requests, which then did not match wiki subdir entries anymore.
Could you check gitlabs nginx access log and post the api get request, e.g.:
tail /var/log/gitlab/nginx/gitlab_access.log
X.X.X.X - - [26/May/2022:08:45:03 +0000] “GET /gitlab/assets/icons-f305926186cfc3bb530f27269d545937c385578ba62adb0088d74f0d2d02cb56.svg HTTP/1.1” 200 39976 “https://XXX/YYY/MyProjectName/-/wikis/MyProjectWiki/REST-Calls” “Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:100.0) Gecko/20100101 Firefox/100.0” -
192.168.10.100 - - [26/May/2022:08:45:03 +0000] “GET /gitlab/api/v4/projects/11/wikis/MyProject%2FREST-Calls?version=5adb4f0fa350bf4322d5db0778ab4cbc2e7ce84c&render_html=true HTTP/1.1” 200 415 “https://XXX/YYY/MyProjectName/-/wikis/MyProjectWiki/REST-Calls” “Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:100.0) Gecko/20100101 Firefox/100.0” 1.61
Espacially check url encoding, in example above, the subdir path must be url encoded:
MyProject%2FREST-Calls
FWIW I’m seeing 404 in logs/nginx/gitlab_access.log when accessing a wiki page in a subdir:
"GET /api/v4/projects/5/wikis/TestFolder/TestPage?version=8c44a01c0a94cb3feefb4732122be4acc80dbde1&render_html=true HTTP/1.0" 404 25 "https://gitlab.example.com/test-group/test-wiki/-/wikis/TestFolder/TestPage" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:100.0) Gecko/20100101 Firefox/100.0" -
I guess it should render fine if:
"GET /api/v4/projects/5/wikis/TestFolder%2FTestPage?version=8c44a0...
In case that your gitlab instance is behind proxy, it might be worth to check that proxy it is not URL encoding the request.
I just updated our GitLab instance from 14.6.0 to 15.1.2 and got the same behaviour.
If you guys like me are using Apache to ProxyPass to a backend instance of GitLab, then the issue for me was solved by setting nocanon on on the ProxyPass directive so that Apache does not url decode when proxying.
You also need to tell apache to not decode the received request.
AllowEncodedSlashes NoDecode
ProxyPass / http://xxx.xxx.xxx.xxx:80/ nocanon
I hope this helps someone! 
Thank you, I believe that is at least part of my problem and earlier @rumble-on had identified it correctly as well.
I’m using nginx as my reverse proxy and changed the proxy_pass directive from:
proxy_pass http://127.0.0.1:8080/;
to
proxy_pass http://127.0.0.1:8080$request_uri;
That has resolved the issue for me 
1 Like