Trailing slash redirects result in 404 when using pathPrefix option

[petershafer]

Redirects implemented in the dev server will add or remove a trailing slash to the path depending on the resource requested at /{path} and the existence of /{path}/index.html or /{path}.html.

These redirects do not account for use of the pathPrefix option and will result in a request to /{prefix}/{path} redirecting to /{path}/ when /{prefix}/{path}/index.html exists.

Similarly, a request to /{prefix}/index/ when /{prefix}/index.html exists will result in a redirect to /index.

All result in HTTP 404 responses this changes the request to something outside of /{pathPrefix}/... and get permanently cached since the redirect is a HTTP 301 redirect.

I've submitted a PR to resolve this issue: #64

[spaceninja]

+1 — We just ran into the same problem. We're outputting our site into a subfolder and using pathPrefix, but our navigation URLs, which come from a CMS, don't include a trailing slash.

• pathPrefix: example is our path prefix
• /example-page is the link from the CMS
• example/example-page is the rendered link in the HTML (which is correct)
• but clicking on the link actually lands you on /example-page (which is a 404)

We've switched back to the BrowserSync server for now, but hoping this gets addressed so we can switch back to the new server.

[zachleat]

Fixed by #64, shipping with Eleventy Dev Server v2.0.0—thank you!