A few usage questions

[agersant]

Hello and thanks for working on Thruster! I have been experimenting with various Rust web frameworks over the past few days to potentially replace my usage of Rocket. So far Thruster has been one of the more promising candidates. I love the simplicity of the API and how easy it is to create, manipulate and pass around the App type.

I have a few questions on how to use the framework correctly:

• Is the best/only way to serve static files to write a middleware which loads the entire file in memory and calls context.body(entire_file_content)? This seems very inefficient if that is the case :(
• Also on the subject of serving static files, how would you recommend matching the trailing portion of a route? For example, let's say I want to make all URL starting with /swagger to serve the corresponding files in a ./docs directory on disk. For instance, hitting /swagger/img/logo.png should serve /docs/img/logo.png
• When using App::create, it would be very useful if it was possible to pass in a closure as the generate_context argument. As it stands, I am not sure how to shove any data that is determined during application startup into the context objects. EDIT: I guess this is the answer: https://github.com/trezm/Thruster/issues/130

Many thanks in advance!

[trezm]

Hello and thanks for using Thruster! :)

I'm glad you decided to try it out, it's awesome to have you here.

Let's see about those questions

• Nope! Actually I'm slowly moving towards encouraging the use of the HyperServer and BasicHyperContext instead of the home-grown thruster versions. The reasons being that hyper is really quick and very well made, and that the home-grown versions are much lighter on features. SO! My recommendation would be to use BasicHyperContext, on which you can actually set the body as hyper::Body which implements stream, so you can stream the files.
• The best way to do this is with a named route parameter, so you'd have a route that was .get("/swagger/img/:file", ...) and then in code you can access the file (test for file types, etc.) using context.params.get("file") which will return an Option<String> that you can unwrap with the value.
• This is something I've been trying to figure out the best API for for a little while. What would be most useful in terms of form for you? The key here is that any reference passed into a closure would need a 'static lifetime, because the context generator is used in a tokio future. Would love to hear thoughts/suggestions!

[agersant]

Thanks for the fast reply!

• Makes complete sense, thank you!
• The issue with this approach is that it tightly couples the code with the structure of the directory being served. As a user, I would like to define a /swagger/... route, not all the variations of /swagger/img, swagger/data, swagger/style or whatever might be in there. Maybe this is an opportunity to extend the routing syntax.
• I changed my stance on this one after reading #130. I can't think of a good reason to use a closure now that I realize Request are only meant to track data pertaining to the request being handled and not application state. I do however wish there was a way to supply application state to Thruster (with whatever trait constraints it needs) instead of using a global / lazy_static which I don't like very much.

[trezm]

Hmm for point number 2 I see what you mean. I think the solution here is to make the route /swagger/* and then make the call for route() on BasicHyperContext. You can then use that route to resolve to the actual file -- beware though! Make sure you use the proper security practices to avoid allowing malicious users entering routes like /swagger/../../../super-secret-password or something like that.

For the last point, I think I have a solution that I've been thinking about over the weekend. I'll post on #130 once I've verified that what I think will work actually will work :)

[agersant]

You can then use that route to resolve to the actual file

How would the code in the handler know which part of route()'s output is the route (eg. /swagger) versus the path that can be mapped to the drive (eg /img/logo.png)?

Good point on watching out for directory traversal attacks, I would have missed that!

[trezm]

Sorry about the delayed response, have been taking care of a few personal things on the outside!

How would the code in the handler know which part of route()'s output is the route (eg. /swagger) versus the path that can be mapped to the drive (eg /img/logo.png)?

Let me restate to make sure I understand the question here:

Given a few routes like this: /swagger/data/doc, /swagger/img/logo.png, /swagger/img/cute-puppies.png, how would you make it so that each route wouldn't have to be individually defined, yet you get the correct behavior of /swagger/data/... hitting a swagger middleware and /swagger/img/... hitting an appropriate path?

I would think something like this would work?

app = App::create(generate_context);

app.get("/data/*", async_middleware!(Ctx, [data_handlers]));
app.get("/*", async_middleware!(Ctx, [general_file_handlers]));

Or I'm misunderstanding the question!

[trezm]

I should also mention that I have a PR coming up soon that should handle async file cacheing and serving as a stream as well!

[trezm]

Closing this for lack of activity