Closed agersant closed 4 years ago
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
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..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.'static
lifetime, because the context generator is used in a tokio future. Would love to hear thoughts/suggestions!Thanks for the fast reply!
/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.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.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 :)
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!
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!
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!
Closing this for lack of activity
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:
context.body(entire_file_content)
? This seems very inefficient if that is the case :(/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
App::create
, it would be very useful if it was possible to pass in a closure as thegenerate_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/130Many thanks in advance!