Hosting environments that add a trailing back slash break page links

[littlespex]

🐛 Bug Report

Hosting setups that add a trailing back slash to urls break all inter-site links on the page.

Have you read the Contributing Guidelines on issues?

Yes

To Reproduce

1. Create a new site using npx @docusaurus/init@next init test-site classic
2. Create two new sub folders in docs called a and b
3. Add attached file a.md to a folder, and b.md to b folder.
   • a.md.zip
   • b.md.zip
4. Replace sidebar.js with attached version.
   • sidebars.js.zip
5. run npm run build to generate the flat site.
6. Load the site in any browser by navigating directly to the url of page a: http://127.0.0.1:8080/docs/a/a
7. Click the link Link to page "b"

Expected behavior

Page b should load.

Actual Behavior

Page Not Found page.

Your Environment

• Docusaurus version used: 2.0.0-alpha.48
• Environment name and version (e.g. Chrome 78.0.3904.108, Node.js 10.17.0): Safari 13.0.5 (15608.5.11), Chrome 80.0.3987.132, Firefox 73.0.1
• Operating system and version (desktop or mobile): macOS 10.15.3 (19D76)

Reproducible Demo

(Paste the link to an example repo, including a siteConfig.js, and exact instructions to reproduce the issue.)

http://littlespex.com/docusaurus/docs/a/a

test-site.zip

[bravo-kernel]

@littlespex are you sure the browser is adding that slash? Try running your site locally and see if the slash gets added. If not, it most likely is your hosting server.

FYI I am seeing the same behavior on Netlify (adding the slash, breaking the links)

[bravo-kernel]

💡 If you are using Netlify, disabling Pretty URLs should solve the problem. I unchecked the first two boxes to prevent Netlify from both lowercasing the urls and.. adding the trailing slash.

[littlespex]

I had updated the ticket description earlier to mention the hosting environment instead of the browser. Unfortunately we don’t have admin control over our docs environment and the team that runs it has enabled these url rewrite rules for other reasons. Our current workaround is to revert to docusaurus v1 which works as expected.

[davidhagg]

We are having this issue too running on an Azure Webservice.

[dotansimha]

Same here, with GH Pages.

[dotansimha]

My current way to workaround that:

1. Create a file called static/js/fix-location.js with:

if (window && window.location && window.location.pathname.endsWith('/') && window.location.pathname !== '/') {
  window.history.replaceState('', '', window.location.pathname.substr(0, window.location.pathname.length - 1))
}

2. Load this file as static JS file in docusaurus.config.js:

  scripts: [
    {
      src: '/js/fix-location.js',
      async: false,
      defer: false,
    },

[cliedeman]

@dotansimha Thanks for the workaround.

Anyone else who uses this fix don't forget to include your baseUrl if your site is not hosted at the root

 scripts: [
    {
      src: '/baseUrl/js/fix-location.js',
      async: false,
      defer: false,
    },

[slorber]

Hey, I found the original issue description not so easy to understand (particularly that md files are in zip files 🤪 that does not help to scan this issue). To clarify the problem, here's what I understand:

• Locally you have a page at /folder/myDoc
• It contains a relative link like myLink, supposed to navigate to /folder2/myTargetDoc
• As this link is relative, the trailing slash added automatically breaks the link, as we now navigate to /folder/folder2/myTargetDoc and to make it work in production, we would have to write [myLink](../../folder2/myTargetDoc)

So this bug is only related to using relative links, is that correct @littlespex ?

Is it the problem you also encounter @davidhagg @dotansimha @cliedeman ? Or is it something else?

We should find a solution to this problem (track #3372), but in the meantime, possible workarounds are:

• using absolute paths [myLink](/folder2/myTargetDoc)
• using fs-based linking (only works for docs) [myLink](../folder2/myTargetDoc.md)

[littlespex]

@slorber I believe this issue happens on any link that does not contain a trailing backslash. We had to revert to docusaurus v1, so I no longer have a working example.

[MarkFarmiloe]

In docusaurus/packages/docusaurus/src/client/normalizeLocation.ts
any trailing /index.html is knocked off the path.
If you knock off any trailing / as well with
pathname = pathname.replace(/\/$/, '');
on line 23, this seems to fix this bug.

But I don't know whether this would break anything else.
But it does seem to me that if you want to normalize, then allowing both /foo/bar/ and /foo/bar doesn't seem to be a very good job of normalizing to me.

[veeramarni]

I'm having the same issue, it breaks URL navigation due to HTTP proxy services. I use `Nginx in the docker, when I directly open a link without trailing slash, it redirects to HTTP domain with the port used in Nginx. Since we don't run on 443 port it breaks the public link.

For example, if I try to open https://domain.com/a it redirects to http://domain.com:8080/a/ and it fails to load the page. But if you open https://domain.com/a/ it works fine. Does anyone have the same issue?

[slorber]

FYI there is a related issue here: #3372 so I'm going to close this one.

I proposed a temporary workaround here: #3372 (comment)

Using client-side normalization is not bad but it won't prevent the host to eventually add a useless server redirect to the URL with a trailing slash.

I used it successfully on React-Native website:

• using Github Pages
• using Netlify with pretty URLs disabled (the global "disable asset optimization" checkbox is broken: make sure "pretty URL" is really unchecked)

The PR I linked to contains a plugin that to will prevent the host to add a trailing slash and prevent a useless server redirect.

Please try my workaround with your specific hosting env, and report on the other issue if the workaround works or not for your usecase.

If the workaround works for everyone, I'll generalize it and add it by default in Docusaurus core, so your feedback is important.