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

Handling trailing slashes for directories #542

Open
mversic opened this issue Feb 4, 2025 · 5 comments
Open

Handling trailing slashes for directories #542

mversic opened this issue Feb 4, 2025 · 5 comments

Comments

@mversic
Copy link

mversic commented Feb 4, 2025

Feature Request

I'm willing to implement this if approved

Motivation

I want to support only non-trailing slash paths. To do this I wrap my router with NormalizePathLayer::trim_trailing_slash().layer. This however doesn't work well with ServeDir which will always redirect to a trailing slash path for directories (/kita -> /kita/). Therefore, it's not possible not to have trailing slashes on paths that correspond to directories.

Proposal

There are 3 possibilities on how to handle paths without a trailing slash for directories:

  1. redirect to trailing slash
  2. return index.html (200)
  3. respond with 404 (not found)

I think an enum of 3 variants should be offered with current behavior (redirect) as the default. Additionally, I think that the 3rd variant would make the append_index_html_on_directories deprecated as it would have the same effect

Alternatives

A solution where I would rewrite URL in a layer before this service would have to access filesystem to verify that path corresponds to a directory. This would incur unnecessary IO reads so it would be best to handle it directly within ServeDir

I'm eager to hear other proposals on how to design this API

@jplatte
Copy link
Collaborator

jplatte commented Feb 4, 2025

I want to support only non-trailing slash paths.

You know that NormalizePath is for supporting both, but without having to check for both variants in routing, right? If you want to send the client a redirect on trailing slash for your non-ServeDir routes, and you are using axum, there is route_with_tsr in axum-extra for this.

@mversic
Copy link
Author

mversic commented Feb 4, 2025

I want to support only non-trailing slash paths.

You know that NormalizePath is for supporting both, but without having to check for both variants in routing, right? If you want to send the client a redirect on trailing slash for your non-ServeDir routes, and you are using axum, there is route_with_tsr in axum-extra for this.

My bad. I want to support both paths (with and without a trailing slash). This is currently not possible with ServeDir for directories

@jplatte
Copy link
Collaborator

jplatte commented Feb 4, 2025

Okay.. So what does your routing setup look like? I would recommend you try to split it into the pieces where the NormalizePath layer makes sense, and those where it doesn't.

@mversic
Copy link
Author

mversic commented Feb 4, 2025

Okay.. So what does your routing setup look like? I would recommend you try to split it into the pieces where the NormalizePath layer makes sense, and those where it doesn't.

I just want to serve directories under no-slash paths

My intention was to serve only paths without trailing slashes and have trailing slash redirect to no slash (opposite of what ServeDir does). This is what tanstack router does, it's configurable in astro, etc. In other words it's quite a common request. I would have been ok with either that or serving both (and using canonical href). However, I can't do either with ServeDir because it is hardcoded to redirect non-slash to slash. I want to serve /kita/index.html under the path /kita (not /kita/).

I have already forked this repository and patched ServeDir to suit my needs. Now I would like to get this into tower-http

@jplatte
Copy link
Collaborator

jplatte commented Feb 4, 2025

Ah, now I understand.

Feel free to send a PR, it sounds like it's going to be a pretty simple one.

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

No branches or pull requests

2 participants