http-rs
Unexpected Behaviour in 0.17.0-beta.1
Hey All - long time no see.
Using 0.17.0-beta.1 - I have a static file server at
app.at("/*").serve_dir(path)?;
And the following additional route defined.
app.at("/:slug/").get(somecall);
When I request http://localhost:8080/index.html I am routed to the app.at(/:slug/).get(somecall); route.
However as the path doesn't contain a trailing slash I would expect it to hit the serve_dir route.
Looking at the tests in https://github.com/jbr/routefinder/blob/main/tests/tests.rs I can't see a way to achieve what I am looking for.
Is the expected behavior?
Edit:
In 0.16 I was using app.at("/").serve_dir(path)?; without the * and it was working as expected.
This is—at least for me—expected behavior. Star routes are the lowest precedence in routefinder. Routefinder also ignores trailing slashes. I haven't thought a lot about how this works with tide in a bunch of months, but it seems like the way I'd describe this behavior verbally would be "if there's a static file at a given request path, serve it. if not, try matching the single-param slug route." This seems to me like the serve-dir behavior should be mounted as a middleware in tide terminology, in order to be able to pass through to the :slug endpoint.
Alternatively, I can look into making trailing slashes optionally semantic, but when I was designing routefinder I came to the design perspective that it's far less frequently desired to route a trailing slash distinctly from the otherwise identical path with the trailing slash stripped. I still believe this is the right behavior for most users (and is what I'd want for trillium, which shares routefinder)
Also — I wouldn't have guessed that it's necessary to mount the serve_dir at "/*". It should work to mount it at "/", I would have expected. But I haven't looked at tide in a while
Thanks @jbr The trailing slash convention comes from the static site generator (SSG) projects that I am integrating with. e.g. gatsby 11ty etc If found it a little odd at first too but it makes sense when dealing with content systems rather that APIs. i.e. a content item maybe more than one file deployed to an endpoint. If routefinder/tide/trillium are interested in supporting SSG folks it might be a handy feature to toggle?
And thanks for the idea of implementing the file serving as middleware it gives me a bailout option.
In many other servers (e.g. express), the router has a strict configuration option - it may be useful to add this for tide routing as well as an option on Server rather than on an individual Route.
let app = tide::new().strict_routing(true);
or
app.at("/foo/:bar").strict(false).get(some_handler);
(or both?)
I don't love that as an API though. @jbr do you have thoughts on a good pattern or method of configuration for the Server? It's very likely that as usage of tide increases, more use-cases for configuration will arise. Tacking on setter-methods feels somewhat icky, but a ServerConfig struct or something of the like may be a bit heavy-handed.
