Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature request: remove extensions from path #96

Open
doowb opened this issue Nov 3, 2017 · 4 comments
Open

Feature request: remove extensions from path #96

doowb opened this issue Nov 3, 2017 · 4 comments
Labels

Comments

@doowb
Copy link

doowb commented Nov 3, 2017

Since send is able to handle finding files when the extensions don't exist in the path, would it be possible to expand the redirect functionality here to remove extensions?

For instance, these redirects would take place:

from to
/login.html /login
/something/index.html /something/

I think this would only happen if the extensions option is already populated with the extensions for send to look for.

@dougwilson
Copy link
Contributor

This seems pretty reasonable. I'm not sure if this would be an option in this module vs an option in send directly, though. One thing we would need to figure out is ambiguity during the redirect and what should happen. For example say you have extensions: ['.html', .htm'] and the request is for /login.htm: does the module need to check for login.html before it would redirect /login.htm to /login? Should it just only redirect if it's the first extension? There are several ways we can go about this, just looking to get the conversation started :)

@doowb
Copy link
Author

doowb commented Feb 7, 2018

does the module need to check for login.html before it would redirect /login.htm

This is a good point. When I opened this, my specific goal was to serve static html files that I had built and viewed from the file system. When viewing from the file system, the .html and index.html parts are necessary, but most static servers handle paths without them. I was looking for a way to keep the links the same, but make the urls look nicer and ensure that relative links will still work.

Now that I'm thinking about it, a middleware that runs before serve-static can do the redirecting without having to complicate this module (or send). The other middleware can use options specific to how it would handle ambiguous extensions like mentioned above.

For the conversation :)... If this was going to go in serve-static, is there a way to do a redirect (or path rewrite) when send emits file? From my understanding that happens just before the file is sent to the response, but I don't know if doing a res.redirect() at that point will work. Also... would it require more than just res.redirect(), meaning is that just an express specific method so more work is necessary to redirect from serve-static?

@dougwilson
Copy link
Contributor

Yea, your goal definitely makes sense 👍 I have done the same in the past with Apache rewrite rules and PHP.

A middleware before this middleware would work, as long as you're OK with the rewrites being "blind" -- as in a request to /foo.html first responds with a redirect to /foo and then gets a 404 because there is no foo.html vs getting a 404 from the first /foo.html. Of course, that may be still be desirable depending on the goal.

Yea, I don't think that this change can be done only in this module; it would require some changes to send at a minimum because there isn't hooks to stop the serving of a file and make it do something else. And yea, res.redirect() is express-specific, but there is a helper in both this module and send that is similar to res.redirect() so we'd just use that instead.

@doowb
Copy link
Author

doowb commented Feb 8, 2018

as long as you're OK with the rewrites being "blind"

That's something I hadn't thought about.

it would require some changes to send at a minimum because there isn't hooks to stop the serving of a file

Makes sense. I might try out some ideas this weekend (these changes aren't urgent since there are other ways to handle it). Thanks for the information and the ideas!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants