How to serve static files from a compiled binary?

[tobymurray]

The guide contains:

This looks like it would be serving a relative path. Looking at the docs, it seems like the path examples are always absolute and to get a relative path the relative! macro should be used.

Naively compiling my Rocket application, my understanding is this will bake in CARGO_MANIFEST_DIR (the path to the crate on the machine building the binary). Obviously this doesn't work for running the machine on a separate host.

How are people serving static files? Are they building them into their binary? Is there an idiomatic way to provide a path at runtime?

[somehowchris]

@tobymurray
So first of all, your shouldn't use rust as a static file server just to use rust. If you need something simple, ngninx or others will do the job and be more efficient, cause they are built for it.

If you still need to serve whole directory cause i.e. you have some auth which can't be handeled by a reverse proxy then fair. Use rust, safe and sound.

Now about handling and including a whole directory in a binary. Your binary needs to be loaded into memory, this means if you got multiple megabytes of css, js, html, wasm or any assets included these would need to be loaded in memory as you start your rocket server. If you would use the traditional way just like nginx, apache and others and put the files into a directory only the ones needed would be loaded into memory. Now I have no clue how much you wanna serve, general rule, if it means your binary will result over 32mb, don't do it, just use the FileServer Method you screenshoted. If your assets are 32mb, that doesn't mean your binary will be 32mb, your binary will be bigger!

Now for the sake of leaving an answer on how to do what you mean. Here we go.... https://docs.rs/include_dir/latest/include_dir/ just include a whole directory in your binary and create a wrapper just like FileServer.

Now you asked how others do it, me, I'm using nginx, cause it does what it needs to do efficiently and silent.

Now if your 3rd question means that you would like to specify the "static/" folder on server startup. It's just a &str, so you can use std::env to get a env variable which you specify

🍺 Cheers

[tobymurray]

your shouldn't use rust as a static file server just to use rust. If you need something simple, ngninx or others....

I'm not doing this, so all good there. I have both static assets and some other stuff (e.g. Tera templates) that are part of a run of the mill web server.

if it means your binary will result over 32mb, don't do it

I have not heard this threshold before - what drives this specific value? Is this platform agnostic? Any links you can share?

just use the FileServer Method you screenshoted

The crux of my confusion here is the FileServer method and rocket_dyn_templates appear to suggest that the host building the machine is the same host executing the binary, and the CARGO_MANIFEST_DIR would have to make sense for it. It's possible I'm misunderstanding the functionality though? E.g. is it just me or does none of rocket_dyn_templates reference deploying a Rocket application?

I understand the value can be changed - the documentation suggests something that seems not to work if the Rocket application is deployed somewhere, which is unexpected to me (and usually suggests I'm missing something). Generally speaking, I would assume following the documentation would lead to "best practices" or at least idiomatic practices. I guess one possibility is most people using Rocket using FileServer are "deploying" by building the binary on the host ultimately serving it, that seems really unlikely to me though.

I'm using nginx, cause it does what it needs to do efficiently and silent.

Something like a Tera template (or any templating framework's template) doesn't seem like a good fit for that, it's not to be served to the web (so no nginx) and if not embedded in the binary then it's some 3rd option? I've seen crates like rocket-include-tera, but the overall concern seems like something a lot of people should be running into. Am I missing something obvious? Should I be zipping my binary + supporting files, replacing any uses of the (to me, misleading) relative! and that's that?

Or put another way, how would one use relative! in a host agnostic capacity?

[blackghost1987]

Rocket can definitely be built and deployed on different machines, at a different path! I don't think you need to put anything IN the binary to achieve that, you can simply zip templates and static files together with your binary and deploy it somewhere.
Template dir is relative to the binary by default, so no worries there.
FileServer is a bit more complicated, I agree the relative! macro has a confusing name. If you want your binary to find the static dir relative to your binary (so you can deploy it anywhere) then you should get rid of relative!, because it would bake in the absolute path. Just use something like FileServer::from("static"), it should work fine.

[somehowchris]

Yes, totally agree with @blackghost1987

Just to clarify @tobymurray

if it means your binary will result over 32mb, don't do it

I have not heard this threshold before - what drives this specific value? Is this platform agnostic? Any links you can share?

Its just advice, an nginx server should start at about 20-32 mb ram, it also has to do with layered caching in cpus cause they would have to load a bunch of stuff if you have all that in your binary. static file servers can offload most of the times these things off the cpu and to some bridge or nic cause many files do not get touched.

just use the FileServer Method you screenshoted
The crux of my confusion here is the FileServer method and rocket_dyn_templates appear to suggest that the host building the machine is the same host executing the binary, and the CARGO_MANIFEST_DIR would have to make sense for it. It's possible I'm misunderstanding the functionality though? E.g. is it just me or does none of rocket_dyn_templates reference deploying a Rocket application?

May I advocate to use a docker build process, no worries about machines and stuff, just an image. If you're fancy, use a multi stage process to have your binary built and then copy only the needed files over to a minimal image.

I'm using nginx, cause it does what it needs to do efficiently and silent.

Something like a Tera template (or any templating framework's template) doesn't seem like a good fit for that, it's not to be served to the web (so no nginx) and if not embedded in the binary then it's some 3rd option? I've seen crates like rocket-include-tera, but the overall concern seems like something a lot of people should be running into. Am I missing something obvious? Should I be zipping my binary + supporting files, replacing any uses of the (to me, misleading) relative! and that's that?

My suggestion: Go for the advice of @blackghost1987 for the code, for having your stuff shipped somewhere, use docker, its self contained and wouldn't harm your system. if you have your prefered system deployment type, go for it, zip them files and unpack them in the same directory as you start the binary

[giuliohome]

FileServer is a bit more complicated, I agree the relative! macro has a confusing name. If you want your binary to find the static dir relative to your binary (so you can deploy it anywhere) then you should get rid of relative!, because it would bake in the absolute path. Just use something like FileServer::from("static"), it should work fine.

Yes, it indeed has a confusing name, and I’ve opened a documentation issue to address it.

Your sentence, quoted above (If you want your binary to find the static dir relative to your binary...), is crystal clear and should be included in the documentation.

[wangjia184]

static PROJECT_DIR: Dir<'_> = include_dir!("$CARGO_MANIFEST_DIR/../web");

#[rocket::get("/<path..>", rank = 100)]
async fn static_files(path: PathBuf) -> (Status, (ContentType, &'static str)) {
    let ext = if let Some(path) = path.extension() {
        path.to_str().unwrap()
    } else {
        ""
    };
    let content_type = match ext {
        "css" => ContentType::CSS,
        "htm" => ContentType::HTML,
        "html" => ContentType::HTML,
        "jpg" => ContentType::JPEG,
        "jpeg" => ContentType::JPEG,
        "png" => ContentType::PNG,
        "gif" => ContentType::GIF,
        "js" => ContentType::JavaScript,
        "json" => ContentType::JSON,
        "txt" => ContentType::Plain,
        "ico" => ContentType::Icon,
        "" => ContentType::Plain,
        _ => ContentType::Binary,
    };

    if let Some(file) = PROJECT_DIR.get_file(path) {
        let content = file.contents_utf8().unwrap_or("");
        return (Status::Ok, (content_type, content));
    }

    (Status::NotFound, (content_type, "Fild not found"))
}

Here is how I do it in rocket v.0.5.0. Register a handler with lowest priority

[SergioBenitez]

Here's a cleaner way that leverages more of Rocket:

#[rocket::get("/<path..>", rank = 100)]
async fn static_files(path: PathBuf) -> Option<(ContentType, &'static [u8])> {
    static PROJECT_DIR: Dir<'_> = include_dir!("$CARGO_MANIFEST_DIR/../web");

    let data = PROJECT_DIR.get_file(&path)
        .map(|file| file.contents())?;

    let content_type = path.extension()
        .and_then(|e| e.to_str())
        .and_then(ContentType::from_extension)
        .unwrap_or(ContentType::Binary);

    Some((content_type, data))
}

[ogarcia]

@SergioBenitez a question, could this be done in the main with mount? (Something like the following but that works):

#[launch]
fn rocket() -> _ {
    static PROJECT_DIR: Dir<'_> = include_dir!("$CARGO_MANIFEST_DIR/../web");

    rocket::build()
        .mount("/web", PROJECT_DIR)
}

[the10thWiz]

Someone could build a Rocket responder, similar to FileServer that take a Dir and responds with the contents of the Dir. However, this would be implemented outside of Rocket, since we don't want to take another dependency (even behind a feature flag), and this would be trivial to implement outside of Rocket.

[ogarcia]

@the10thWiz Could you give an example of how to achieve this? Even if it is not supported code it would not hurt and it would be documented for laymen like me.

[the10thWiz]

I took a stab at this, and published rocket-include-dir.