Recursively Adding Trailing Slash

[daveberning]

trafficstars

It appears that the module is recursively adding a trailing slash to the to new URL.

• Node: 12.8.0
• Yarn: 1.17.3
• Nuxt: 2.11.0
• Redirect Module: 0.3.1

Redirect Rule:

{ from: "/blog/post", to: "/blog/category/post" , statusCode: 301 }

Expected Result:

I expect the URL /blog/post or /blog/post/ (trailing slash) to redirect to /blog/category/post/.

The Problem:

When I visit /blog/post/ the Nuxt site will redirect to /blog/category/post// and the page results in a 404 error and shows my Not Found page.

If I were to visit /blog/post// (notice the double slash), it'll redirect me to /blog/category/post/// and so on. This is a really nice module but this is a big issue considering we cannot control how the user enters the URL. The module works fine if you visit the URL without the trailing slash but that's a specific use case.

---

To provide some background on this project. I am helping convert my employer's website from a SPA Vue app to an SSR Nuxt app. On the Vue app, we have Nginx rules in place and they work as expected.

If you need more information, please let me know!

[ryanrhughes]

Not the greatest solution, but update the to: values to not have a trailing slash made it work well enough. https://github.com/ThinkOodle/oodle.io/commit /f9729c8b8407b3bac2a3498c28e498b537322090

There's still inconsistency that I'm not a fan of and may bite us later.

Example: https://oodle-io.herokuapp.com/blog/3-reasons-digital-campaign-failed/ redirects to https://oodle-io.herokuapp.com/blog/Digital-Advertising/3-reasons-digital-campaign-failed/

https://oodle-io.herokuapp.com/blog/3-reasons-digital-campaign-failed redirects to https://oodle-io.herokuapp.com/blog/Digital-Advertising/3-reasons-digital-campaign-failed

[derz]

@daveberning you should probably handle the trailing slashes via nginx. And since the rules are converted to regex you should then match for start/end of the string:

{ from: "^/blog/post/$", to: "/blog/category/post" , statusCode: 301 }

[daveberning]

@derz well the point of this module is to have control over rewrites when you don’t have access to server configurations. Dipping into Nginx configs defeats the whole purpose of this module.

For this specific project, we moved from an Nginx environment to Heroku. So we previously had Nginx rules (which we coped and use in this module). Unfortunately. we don’t have that luxury on Heroku now.

This is especially an issue if I were to pass along a completed site to a client. You can’t expect them to dip into server configurations.