kettle11 / devserver Goto Github PK

Hi,

I guess most people who use devserver with the 'reload' option generate the content of their website automatically.

At startup, for a clean build, I currently delete the folder that devserver watches, and I restart my app automatically via cargo watch when the code changes.

Unfortunately, that triggers a reload which ends in a 404 error because the file does not exist yet.

I think it would make sense not to reload on deletes.

Basically, you'd just return false from this match arm.

This would also be consistent with how renames are handled.

What do you think?

What is the difference between this crate and http (host these things please) crate https://github.com/thecoshman/http? I saw that this have live-reload.

Presently now index.html is served for only the top-level directory, but index.html should attempt to be served when requesting any directory.

The WebSockets to signal reload use ws and must instead use wss.

This manifests as annoying errors in the developer console.

Hi,

cargo install devserver installs devserver to '~/.cargo/bin/devserver' (on Linux).

Executing '~/.cargo/bin/devserver', however, failes with the above error.

If you change the line let args: Vec<String> = env::args().collect(); to let args: Vec<String> = env::args().skip(1).collect(); and remove the match arm "devserver" => {} it should work as expected.

However, I think you should just use a command line argument parser instead.

By the way, I read most of the code, and I'm wondering why you didn't use crates for most of the stuff?

You wrote somewhere that you want to keep devserver simple, but I think this approach makes it much more complex and error-prone.

For example, for WebSockets there is the fantastic tungstenite, for the argument parse I'd use strucktopt (probably overkill, but there are smaller crates), for the HTTP server tiny_http looks great, and for MIME types there is mime_guess.

The code probably would be 1/5th, if you would use these crates.

This is not an issue. Just a very tiny little suggestion.
But not that important anymore as URLs are anyway most time clickable in terminals now.

In case of implementation one should take default HTTPS or HTTP.

Implementation detail:

# Windows
cmd c/ start url

# Darwin
open url

# Linux
xdg-open url

This way we can avoid pulling in the TLS deps when we have no use for https.

Right now if a .html file is not found devserver returns a 404, but it would be more easily noticed if a 404.html page were served.

Additionally with the current behavior if a page is quickly removed and then it's possible that devserver will refresh in the middle and return a 404 breaking development flow. A proper 404.html page would have the embedded reload script and so it would properly refresh to the final page.

A partial mitigation was proposed and implemented in this issue: #11. This mitigation does not fully solve the issue. If File A is deleted then added and File B is modified then File A could still return a 404 and the browser returns a page without the refresh script.

Many users developing static websites may have their own custom 404 page. A brief survey of existing development servers should be done to learn what the status quo for serving 404 pages is. Do they offer a flag to specify the path to the 404 file?

As pointed out by @cwfitzgerald devserver doesn't match the convention of other Rust/Python/Ruby servers when specifying the directory to host and the port.

Other tools use -p to specify the port and a free argument to specify the directory.

Hey, great tool! I'm getting a crash when I run on fedora, seems the cert is too small:

Serving [...] at [ https://localhost:8080 ] or [ http://localhost:8080 ]
Automatic reloading is enabled!
Stop with Ctrl+C
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Normal(ErrorStack([Error { code: 336245135, library: "SSL routines", function: "SSL_CTX_use_certificate", reason: "ee key too small", file: "ssl/ssl_rsa.c", line: 301 }]))', /home/arlyon/.cargo/registry/src/github.com-1ecc6299db9ec823/devserver_lib-0.1.7/src/lib.rs:121:47
stack backtrace:
   0: rust_begin_unwind
             at /rustc/18bf6b4f01a6feaf7259ba7cdae58031af1b7b39/library/std/src/panicking.rs:475
   1: core::panicking::panic_fmt
             at /rustc/18bf6b4f01a6feaf7259ba7cdae58031af1b7b39/library/core/src/panicking.rs:85
   2: core::option::expect_none_failed
             at /rustc/18bf6b4f01a6feaf7259ba7cdae58031af1b7b39/library/core/src/option.rs:1221
   3: devserver_lib::run
   4: devserver::main
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

Here's the failing line:

Should we regenerate and bundle a new cert? Seems the error happens when using keys equal or less than 2048 in length

thread '<unnamed>' panicked at 'called `Result::unwrap()` on an `Err` value: Os { code: 32, kind: BrokenPipe, message: "Broken pipe" }', /Users/iank/.cargo/registry/src/github.com-1ecc6299db9ec823/devserver_lib-0.1.3/src/lib.rs:96:17 note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace ^C

Put Macbook to sleep and came back from sleep and devserver had crashed.

"devserver --reload" sometimes reloads when the file is only partially written. This gives me half a web page in the browser.

It would be useful to be able to specify a delay between the last change made to a file and when the file is reloaded. This might default to 200ms.

Hi! I came across an issue where send_websocket_message is invoked and a message is sent to the connected clients. I tried sending path.to_path_buf().to_str().unwrap() and it works. However, when I read the file's content (12 lines of HTML), converting it to a slice and sending it, I get the following error in the browser:

WebSocket connection to 'ws://localhost:8129/' failed: Invalid frame header

Tools

Browser: Chrome 81.0.4044.138 (Official Build) (64-bit)
Platform: Windows 10 OS Version 1903 (Build 18362.778)
Rustup toolchain: nightly-x86_64-pc-windows-msvc (default & active)

Hi,

Thanks for creating devserver! :)

The code contains the following:

    let extension = path.extension().and_then(OsStr::to_str);

    // If no extension is specified assume html
    let path = if extension == None {
        path.with_extension("html")
    } else {
        path.to_owned()
    };
    let extension = extension.unwrap_or("html");

I think that is a pretty unexpected behavior (at least for me ;)), because – as far as I know – URLs don't need to have an extension.

I'm working on a static-site-generator and I'd prefer it if my URLs don't contain an unnecessary ".html" extension. Would it, therefore, be possible to remove this code?

Several 3rd party libs rely on arguments such as foo.css?hash=60abbfc70f76d949a785a65742f2a3628c9fe006 or materialdesignicons-webfont.ttf?v=5.8.55. Most often a trick to allow caching (by a CDN or fileserver), but refresh the cache when a new version is rolled out.

devserver then gives an error: Could not find file: /home/redacted/css/fonts/materialdesignicons-webfont.woff2?v=5.8.55

When I create that file, e.g. by adding as symlink, it gets served:

While this "hack" works, it requires changes to the source-code that I'd rather not make.

Ideally, for me, this would work as follows:

When requesting /foo.html?bar=baz

• If a file foo.html?bar=baz exists, serve that.
• If no exact file exists, serve foo.html

This way, a static site that is stored from e.g. crawling/mirroring can be served, preserving url-arguments. But in many development-cases, we can ignore any url-arguments and serve the assets and files without the url-arguments.

Some edge-cases to ignore, or consider:

• How to deal with /foo.html?name=elmo&species=monster versus /foo.html?species=monster&name=elmo.
• How to deal with /foo.html?name=elmo&species=monster when a file /foo.html?name=elmo exists.
• How to treat URL-encoded: /foo.html?name=e%26b must it match the file /foo.html?name=e&b?

If this is considered a good feature, I'll try to make a PR that implements the simple version. And if an edge-case is considered crucial, I'll try to include that too.

Allow users to configure server headers, either with a command line option, a environmental variable option or a Devserver.toml type of configuration.
Devserver.toml

[headers]
Access-Control-Allow-Origin = "*" # Allow CORS

CLI

devserver --headers Access-Control-Allow-Origin="*"

Env

DEVSERVER_HEADERS="Access-Control-Allow-Origin='*'"

Out of these (In my opinion at least) the config file option seems the best, as it allows further expansion of configuration in the future

livereload does this with this project, and it's amazing for developing when you don't have to constantly refresh the browser

See this issue: kettle11/koi#4

Hello, thanks for making devserver - it's super useful!

I'm running into an issue where devserver panics as soon as I start it up:

Serving [/home/reilly/source/proj/] at [ https://localhost:8080 ] or [ http://localhost:8080 ]
Automatic reloading is enabled!
Stop with Ctrl+C
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Normal(ErrorStack([Error { code: 50856204, library: "digital envelope routines", function: "inner_evp_generic_fetch", reason: "unsupported", file: "crypto/evp/evp_fetch.c", line: 349, data: "Global default library context, Algorithm (RC2-40-CBC : 0), Properties ()" }]))', /home/reilly/.cargo/registry/src/github.com-1ecc6299db9ec823/devserver_lib-0.4.1/src/lib.rs:136:62
stack backtrace:
   0: rust_begin_unwind
             at /rustc/7737e0b5c4103216d6fd8cf941b7ab9bdbaace7c/library/std/src/panicking.rs:584:5
   1: core::panicking::panic_fmt
             at /rustc/7737e0b5c4103216d6fd8cf941b7ab9bdbaace7c/library/core/src/panicking.rs:143:14
   2: core::result::unwrap_failed
             at /rustc/7737e0b5c4103216d6fd8cf941b7ab9bdbaace7c/library/core/src/result.rs:1749:5
   3: devserver_lib::run
   4: devserver::main
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

I'm on the new Fedora 36 which adopted OpenSSL v3, and I'm pretty sure that's related. The recently released Ubuntu 22.04 is also on OpenSSL v3 so it might be impacted too.

I'm able to work around this by adding the following to the Cargo.toml for devserver_lib:

openssl = { version = "0.10.40", features = ["vendored"]}

That forces devserver to build and statically link its own copy of OpenSSL. I'm not totally sure if it's the best way to fix this though.