mufeedvh / binserve Goto Github PK

v0.2.0-draft

• Automatic HTTPS/TLS - This initiates a scheduler based on the certificate's expiry date which executes certbot to renew certificates on demand on top of rustls.
• Performance: - Static pages will be cached in-memory on top of dashmap which is configurable depending on the size of the required pages. For the other files, utilize sendfile(2) on supported targets.
  • https://docs.rs/sendfile/latest/sendfile/
  • https://github.com/tailhook/tk-sendfile
  • rust-lang/rust#60689 (comment)
• #31
• Handlebars Partials: Support for handlebars partials. (Ref) (Tag: #23 #27)
• SEO - Metadata generation of robots.txt, sitemap.xml, and JSON search engine schema, (port from gisture).
• Cache-Control Headers - Reference
• Prometheus Metrics - Reference (Thanks to #5 for the suggestion)
• Serve directories - Generate permalinks/slugs from directories in the configuration.

Hi
It would be great if you add a production-ready Dockerfile
Thanks

Hi,
I have a static web app generated from nuxt.
Problem:
When I press a reload button I get an Error 404. This only happens in binserve windows. With the exact same config and same public folder this error does not happen in linux.
I also tested the static page with caddy and simple-http-server and it worked. Not as fast as with binserve, but it works. ;-)

The page was created by a third party and I'm no html/javascript expert.
The nuxt button component is written like this and vue-router is 3.6.x:

<template>
  <v-btn
    class="reset-button"
    @click="resetState"
    outlined
    elevation="1"
    :ripple="false"
  >
    <v-icon>mdi-refresh</v-icon>Start Fresh
  </v-btn>
</template>

<script>
import { defineComponent } from 'vue';

export default defineComponent({
  name: "Reload",
  setup() {
    const resetState = () => {
      location.reload();
    };

    return {
      resetState,
    };
  },
});
</script>

But since it works on linux and on other web server, I guess this must be some error or something i did not configure right.

binserve.json

{
    "server": {
        "host": "127.0.0.1:3000"
    },

    "routes": {
        "/": "public"
    }, 

    "config": {
        "enable_hot_reload": false,
        "fast_mem_cache": false,
        "enable_cache_control": true,
        "enable_directory_listing": false,
        "minify_html": false,
        "follow_symlinks": false,
        "enable_logging": false
    }
}

I tried several combinations of the config settings. Does not seem to make a difference.
Some clarification about the paths in the docs would be nice, especially for the windows case.

As exploring through your project, I found that it does not have API documentation. It is very necessary, especially for new contributors that they are provided with it so it is easier for them. It is also helpful for people like us who sometimes need reference to a function or a struct

It seems you haven't written binserve simultaneously writing code and docs, feel free to tell me if you need help while writing the docs

Every function in the configuration file should be documented in detail as to what it does and how it works, currently it's just a dump of the JSON file and doesn't go into detail on any of the options.

A file called DOCUMENTATION.md should be created for this outside of the README.

Waiting reproducible test case.

Currently index files are assumed to be files starting with index and ends with .html or .htm, this should be configurable. Along with that, there should be an option to exclude specific files from being served.

binserve doesn't detect config changes or file modifications.

According to some of the information on handlebars, you should add a .hbs extension. You can replace all ..html with it or add it after the .html. This change can help some IDEs such as VSCode which has both HTML filetype as well as HBS filetype. You should also change the filenames in the setup_static function as well as setup_404 function

I was inspecting your sources, The ASCII art didn't looked good in the middle of the source code. It would be better if you move it to a separate file or maybe make it a const. Also the line that tells about the host and port could be put along with the ASCII art. You should use the include_str! macro to include it into the source code during compilation and use it in the println! also specifying the host and port

A feature/option to minify HTML pages which can be specified in the binserve.json configuration file just like directory_listing.

{
  ...
  "minify_html": true,
  ...
}

Support for Subresource Integrity, automatically generating hashes for served static content, would boost the security.

It would be great if you could specify which paths are available and for who (authN+Z)

binserve seems really great but I really wish it were a bit easier to use:

1. It would be really great to be able to just do binserver --auto-self-signed-tls --dir ./www and have it generate a self-signed key/cert and serve from the directory.
2. I have no idea how to generate certs/keys for this. I have my openssl one-liner and if I try to use that I get:

[cole@slynux:~/code/webrtcsink]$ openssl req -x509 -newkey rsa:4096 -keyout key.pem -out cert.pem -sha256 -days 365                                                                        
redacted....


[cole@slynux:~/code/webrtcsink]$ binserve
[INFO] Build finished in 485 μs ⚡
[INFO] Enabled TLS (HTTPS) 🔒
[SUCCESS] Your server is up and running at 0.0.0.0:8001 🚀
[ERROR] Could not locate PKCS 8 private keys.

Supporting nonce generation for Contenct Security Policy (CSP) HTTP header would greatly help boost defence against contect injection.

When a config file is incomplete binserve should use secure defaults instead of panicing. When a config file is malformed there should be an understandable error message and an exit with a non-zero status code.

Ran in alpine:latest container:

# ./binserve-v0.1.0-x86_64-unknown-linux-musl
thread 'main' panicked at 'called `Option::unwrap()` on a `None` value', src/security.rs:109:47
stack backtrace:
   0:           0x65daaa - std::backtrace_rs::backtrace::libunwind::trace::hf222ece681d618dd
                               at /rustc/7f7a1cbfd3b55daee191247770627afab09eece2/library/std/src/../../backtrace/src/backtrace/libunwind.rs:96
   1:           0x65daaa - std::backtrace_rs::backtrace::trace_unsynchronized::h7bfcf0be2fa82989
                               at /rustc/7f7a1cbfd3b55daee191247770627afab09eece2/library/std/src/../../backtrace/src/backtrace/mod.rs:66
   2:           0x65daaa - std::sys_common::backtrace::_print_fmt::h236d9b171ad18828
                               at /rustc/7f7a1cbfd3b55daee191247770627afab09eece2/library/std/src/sys_common/backtrace.rs:79
   3:           0x65daaa - <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt::h4b36b828e94cdbaa
                               at /rustc/7f7a1cbfd3b55daee191247770627afab09eece2/library/std/src/sys_common/backtrace.rs:58
   4:           0x54eb3c - core::fmt::write::h0dd4368b249898df
                               at /rustc/7f7a1cbfd3b55daee191247770627afab09eece2/library/core/src/fmt/mod.rs:1080
   5:           0x65d1b1 - std::io::Write::write_fmt::hc892ee261e6ddf46
                               at /rustc/7f7a1cbfd3b55daee191247770627afab09eece2/library/std/src/io/mod.rs:1516
   6:           0x65cb9d - std::sys_common::backtrace::_print::h8b2bc12d86f6d6ce
                               at /rustc/7f7a1cbfd3b55daee191247770627afab09eece2/library/std/src/sys_common/backtrace.rs:61
   7:           0x65cb9d - std::sys_common::backtrace::print::ha0d71e055133e020
                               at /rustc/7f7a1cbfd3b55daee191247770627afab09eece2/library/std/src/sys_common/backtrace.rs:48
   8:           0x65cb9d - std::panicking::default_hook::{{closure}}::h1db1a3550f89322b
                               at /rustc/7f7a1cbfd3b55daee191247770627afab09eece2/library/std/src/panicking.rs:208
   9:           0x65c222 - std::panicking::default_hook::hfe146431cb18e73a
                               at /rustc/7f7a1cbfd3b55daee191247770627afab09eece2/library/std/src/panicking.rs:227
  10:           0x65c222 - std::panicking::rust_panic_with_hook::hef9392580f57df9b
                               at /rustc/7f7a1cbfd3b55daee191247770627afab09eece2/library/std/src/panicking.rs:577
  11:           0x65bf08 - std::panicking::begin_panic_handler::{{closure}}::hc22f01b65500c5e4
                               at /rustc/7f7a1cbfd3b55daee191247770627afab09eece2/library/std/src/panicking.rs:484
  12:           0x65bed4 - std::sys_common::backtrace::__rust_end_short_backtrace::h23c7f1d7574039e8
                               at /rustc/7f7a1cbfd3b55daee191247770627afab09eece2/library/std/src/sys_common/backtrace.rs:153
  13:           0x65be8d - rust_begin_unwind
                               at /rustc/7f7a1cbfd3b55daee191247770627afab09eece2/library/std/src/panicking.rs:483
  14:           0x54d360 - core::panicking::panic_fmt::h5f46bd9f58c47694
                               at /rustc/7f7a1cbfd3b55daee191247770627afab09eece2/library/core/src/panicking.rs:85
  15:           0x54d17c - core::panicking::panic::hfc8a9856fb2eca80
                               at /rustc/7f7a1cbfd3b55daee191247770627afab09eece2/library/core/src/panicking.rs:50
  16:           0x4130aa - binserve::binserve_init::hc5b7ef2db614b4b6
  17:           0x522db2 - std::thread::local::LocalKey<T>::with::h16e9249519e7350b
  18:           0x522ab6 - std::thread::local::LocalKey<T>::with::h14c0541cdbdc56bc
  19:           0x414810 - binserve::main::h5a440c368087745b
  20:           0x522943 - std::sys_common::backtrace::__rust_begin_short_backtrace::h413f99a6607c1379
  21:           0x415a58 - main
Panic in Arbiter thread.

Content of the config file:

{}

I'm unable to build the binary on my mac.

Build:

$ cargo build
    Updating crates.io index
 Downloading actix-web v3.0.2
error: unable to get packages from source

Caused by:
  failed to parse manifest at `/Users/xxx/.cargo/registry/src/github.com-1ecc6299db9ec823/actix-web-3.0.2/Cargo.toml`

Caused by:
  feature `rename-dependency` is required

this Cargo does not support nightly features, but if you
switch to nightly channel you can add
`cargo-features = ["rename-dependency"]` to enable this feature

System:

$ uname -a
Darwin xxx 19.6.0 Darwin Kernel Version 19.6.0: Mon Aug 31 22:12:52 PDT 2020; root:xnu-6153.141.2~1/RELEASE_X86_64 x86_64

Cargo version:

$ cargo --version
cargo 1.30.0 (a1a4ad372 2018-11-02)

The actix_web's newest stable release re-exports actix_rt::main. So you probably should change your main function to this

#[actix_web::main]
async fn main() -> std::io::Result<()>  {

And append main to the use line of actix_web in the main.rs file.

You should also probably remove actix-rt from the dependencies list in your Cargo.toml because I do not see any other use for it.

I should have filled up a PR but I didn't had the time to fork, change and file it. Also I didn't fully studied your codebase

Exposing Prometheus metrics would help productionize this tool. It seems there's already a crate (actix-web-prom that interacts with actix-web.

• https://lwn.net/Articles/542629/
• Ref: actix/actix-web#91
• Ref: https://actix.rs/actix-web/actix_web/struct.HttpServer.html#method.listen

Currently, the configuration file is saved as an environment variable instead of reading the file on every request so as to improve performance but how about storing that in cache? We need more speed! ⚡🔥

I am gonna implement this but I am kinda busy at the moment so if you want to do this, I would really appreciate it 🙌⬇️

You wanna do this?

Here's everything you need:

All the functions for configuration are in the config.rs file.

Here is the function that stores the config:

Lines: L15-L22

fn save_config() -> std::io::Result<()> {
    let config_file = File::open(CONFIG_FILE)?;
    let mut buf_reader = BufReader::new(config_file);
    let mut json_string = String::new();
    buf_reader.read_to_string(&mut json_string)?;
    env::set_var("JSON_CONFIG", json_string);
    Ok(())
}

Here is the function that fetches the config:

Lines: L65-L72

pub fn get_config() -> serde_json::Value {
    let bs_config = env::var("JSON_CONFIG").unwrap();

    let json_config: serde_json::Value =
        serde_json::from_str(&bs_config).expect("JSON was not well-formatted");

    json_config
}

Just change these two functions to store the config in the cache and fetch it from the cache respectively! ⚡

@luciusmagn suggested this feature, Thank You! 🙌

i.e. rerouting domains and routes to different ports on the machine

Multiple domains are not handled at the moment, I will probably think about adding this.

Implementation

Here is how I am planning to implement this feature.

The configuration will look like this, just use a hostname:port combination instead of static file route to configure. simple.

"routes": {
    "/": "index.html",
    "/example": "example.html",
    "/blog": "blog.example.com",
    "/staging": "blog.example.com:8080"
},

While checking for routes, it reads the file (NamedFile()) and responds with the corresponding Content-Type at the moment, this feature should require a check for hostname/file validation before the response.

SIDE NOTE: This might be expensive in performance, in-memory/cached handling of the configuration would be a workaround?

Hey,
Unicoded Emojies like 😋 📙 are not Getting Rendered Properly.

Eg:
If I edit my "template_variables" in binserve.json to

"template_variables": {
"load_static": "/static/",
"name": "This is test 😋"
}

The Index page get rendered as 👇

And I believe this is something that should be fixed! Right?

OS:Windows 10 64Bit
Binserve used : binserve-v0.1.0-x86_64-pc-windows-gnu.exe

E.g., the port, whether to have dir listings, whether to follow symlinks, etc.

Writing a config file is kind of overkill for firing up a throwaway HTTP server.

PS: Adding some screenshots of the directory listings will also help adoption.

I would not like to call this an issue (maybe it is) but rather a question. So you describe in the README on how you can use the template_variables key in the binserve.json file to serve variables. This got me a question about how can someone integrate with other Rust libraries like Diesel so that it can interact with a database or maybe something even simple like getting some information from the URL.

I didn't got any links to Documentation and the README didn't said enough so I filled this issue

Hi,

I'd be much interested in having binserve provide HTTPS support with both automatically generated self-signed certificate or cert/key file as input.

As far as I know it cannot be found within the Rust command-line tools. For instance, Miniserve has yet to implement it.

Cheers, and thanks for your work and dedication !

It would be great if we could define partials and reference them in our templates. Ideally, I'd like to define a single layout template with a content block which could be filled in by a number of other templates.

I'd be happy to implement this if that would help, but I would like some guidance on how you'd like it integrated if I were to create a PR.

Thanks for the awesome project BTW 💯

Currently for convenience, a configuration file is generated on the first run and is always consumed from the same working directory as the binary is executed. This implementation was to make project separation easier but comes with an overlooked issue where the executable file could/should be placed outside of a project directory.

This is a tracking issue alongside #32 to implement override for every configuration functions.

Thanks for the project, it is really awesome!

Right now, the configuration file is hardcoded to be read from the current directory. Sometimes it becomes necessary to run binserve from a directory which does not have a binserve.json. In this case, it would be great if we have the option to specify the location of the configuration file.