svenstaro / miniserve Goto Github PK

The auth error handling right now is quite verbose. I'm sure it can be done better and more neatly.

miniserve is becoming a little more complex than I anticipated and we should get at least some testing infrastructure in place.

When I ran make, it started running a release build for Linux on my Mac ⁉️

It's because that task is simply the first in the Makefile.

I'd expect make alone to build whatever is appropriate for my system.

The more features miniserve provides, the longer the file get.

Currently, miniserve follows symlinks. There should be an option to not have it do that.

We're hiding all the other parameters if they are the default but the default theme slipped by somehow and is now always visible in the URL which leads to untidy URLs. It should be hidden like the other parameters.

cargo install miniserve

    Updating crates.io index
  Installing miniserve v0.4.1
   Compiling semver-parser v0.7.0
   Compiling libc v0.2.55
   Compiling autocfg v0.1.2
   Compiling proc-macro2 v0.4.30
   Compiling rand_core v0.4.0
   Compiling byteorder v1.3.1
   Compiling unicode-xid v0.1.0
   Compiling arrayvec v0.4.10
   Compiling cc v1.0.37
   Compiling syn v0.15.34
   Compiling lazy_static v1.3.0
   Compiling cfg-if v0.1.9
   Compiling version_check v0.1.5
   Compiling stable_deref_trait v1.1.1
   Compiling nodrop v0.1.13
   Compiling memchr v2.2.0
   Compiling smallvec v0.6.9
   Compiling scopeguard v0.3.3
   Compiling memoffset v0.2.1
   Compiling fnv v1.0.6
   Compiling failure_derive v0.1.5
   Compiling encoding_index_tests v0.1.4
   Compiling futures v0.1.27
   Compiling slab v0.4.2
   Compiling matches v0.1.8
   Compiling rustc-demangle v0.1.14
   Compiling siphasher v0.2.3
   Compiling percent-encoding v1.0.1
   Compiling arc-swap v0.3.11
   Compiling quick-error v1.2.2
   Compiling linked-hash-map v0.5.2
   Compiling serde v1.0.91
   Compiling crc32fast v1.2.0
   Compiling ryu v0.2.8
   Compiling num-traits v0.2.6
   Compiling itoa v0.4.4
   Compiling safemem v0.3.0
   Compiling untrusted v0.6.2
   Compiling num-integer v0.1.39
   Compiling regex v1.1.6
   Compiling bitflags v1.0.4
   Compiling ucd-util v0.1.3
   Compiling httparse v1.3.3
   Compiling string v0.1.3
   Compiling unicode-width v0.1.5
   Compiling indexmap v1.0.2
   Compiling utf8-ranges v1.0.2
   Compiling dtoa v0.4.4
   Compiling unicode-segmentation v1.3.0
   Compiling ansi_term v0.11.0
   Compiling language-tags v0.2.2
   Compiling vec_map v0.8.1
   Compiling sha1 v0.6.0
   Compiling strsim v0.8.0
   Compiling lazycell v1.2.1
   Compiling literalext v0.1.1
   Compiling maud_htmlescape v0.17.0
error[E0554]: #![feature] may not be used on the stable release channel
  --> /home/simon/.cargo/registry/src/github.com-1ecc6299db9ec823/literalext-0.1.1/src/lib.rs:19:37
   |
19 | #![cfg_attr(feature = "proc-macro", feature(proc_macro))]
   |                                     ^^^^^^^^^^^^^^^^^^^

error: aborting due to previous error

For more information about this error, try `rustc --explain E0554`.
error: Could not compile `literalext`.
warning: build failed, waiting for other jobs to finish...
error: failed to compile `miniserve v0.4.1`, intermediate artifacts can be found at `/tmp/cargo-installR6Shb6`

Caused by:
  build failed```

It'd be great if running miniserve without any arguments served the current working directory.

I'd be happy to make this change, by giving the PATH argument a default of ., if this is amenable.

The current behaviour of miniserve if set to --port=0 is to accept it (valid u16). However, this is not a "valid" port (actually, it is valid, but shouldn't be used as such), an address like 127.0.0.1:0 is not valid .

Chrome's message:

This site can’t be reached
The web page at http://127.0.0.1:0/ might be temporarily down or it may have moved permanently to a new web address.
ERR_ADDRESS_INVALID

By convention (I don't know if there's a spec for it ?), addressing a system on port 0 means "give me whatever port you want", usually from 49152 to 65535.

So, we have 2 solutions here:

• either we make the port 0 invalid, exception caught at startup, no big deal
• or we implement such a feature if you think that's worth it: generate a random port from 49152 to 65535 and use it. Note that Python's http.server implements this feature

In short, either a bug fix, or a new feature :)

Currently, our argument parsing is fine but not too neat. We should look into using https://github.com/TeXitoi/structopt to tidy it up.

I have the same folder shared via Samba which requires specific user and file/directory permissions. If I upload through miniserve, it uses current user and creates file with 644 permissions. Anyway to change this behaviour to use "nobody.nogroup" and file permissions to 775?

I actually had this requirement a few minutes ago that I wanted to see the modified date in the file listing.

Perhaps it would be useful to also allow users to upload files. Investigate.

It'd be great if miniserve has SSL support.
(Since SSL is a complex stuff, maybe it's against the simplicity policy of miniserve, though)

Miniserve is great but it takes a long time to install when having to compile it. It'd be awesome if I could install it through Homebrew as a part of my development team's standard workstation configuration.

I can do up the formula if no one else gets to it first. I think miniserve meets the notability requirements now (age and number of GitHub stars).

We're currently attackable using timing attacks. We might want to add a constant time password comparison. There is one in ring that's easy to use.

Summary

Right now, the only way to "configure" miniserve is via command-line arguments

miniserve --interfaces ::1 --port 8080 --auth user:sha256:hash $@

But it would be more convenient to have a global configuration file for recurring command-line options

# manifest version, it allows us to warn users when a breaking change is introduced
version: 0

# configuration values, almost identical to command-line arguments
config:
  interfaces: ['::1']
  port: 8080
  auth: 'user:sha256:hash'

Discussion

• Which format should we use? RON, TOML or YAML?
• Where to locate configuration files? ~/.miniserverc.$ext, ~/.miniserve/config.$ext, ~/.config/miniserve/config.$ext?
• What to do when configuration file is invalid? Ignore, Warn, Error?
• Which library should we use? (For now, I recommend serde)

I suppose this should ignore the command-line provided sort options. Also this should be appended to the URL like so: localhost:8080?sort=date&order=desc.

What would you think about having a search bar to search for files in the listing ? I think that would be pretty useful for mobiles, when you can't easily CTRL+F. If that's an idea you like, I think we should make it compatible with both Javascript and no-Javascript users.

I was thinking:

The search bar has a "Search" button. When clicking on it, the searched term is put as query parameter ?search=foobar, then the server generates a page corresponding to that filtering. That would be compatible with no-javascript user. If Javascript is enabled, we simply hide the search button, and the filtering is performed in live using Javascript.

Problem

The miniserve AUR right now compiles to code, which takes time.

I also have my own AUR but it's inconvenient for me to update it on every release.

Suggestion

Integrate the process of AUR deployment into Travis CI.

Clippy is a linter for Rust. It prevents us from making common mistakes. I've recently tried running cargo clippy for main.rs and this is what I got:

    Checking miniserve v0.4.1 (/home/khai/programming/miniserve)
warning: writing `&Vec<_>` instead of `&[_]` involves one more reference and cannot be used with non-Vec-based slices.
  --> src/auth.rs:78:56
   |
78 | pub fn compare_hash<T: Digest>(password: String, hash: &Vec<u8>) -> bool {
   |                                                        ^^^^^^^^ help: change this to: `&[u8]`
   |
   = note: #[warn(clippy::ptr_arg)] on by default
   = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#ptr_arg

warning: identical conversion
   --> src/listing.rs:159:18
    |
159 |     for entry in dir.path.read_dir()? {
    |                  ^^^^^^^^^^^^^^^^^^^^ help: consider removing `dir.path.read_dir()?()`: `dir.path.read_dir()?`
    |
    = note: #[warn(clippy::identity_conversion)] on by default
    = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#identity_conversion

warning: this function has too many arguments (11/7)
  --> src/renderer.rs:12:1
   |
12 | / pub fn page(
13 | |     serve_path: &str,
14 | |     entries: Vec<Entry>,
15 | |     is_root: bool,
...  |
86 | |     }
87 | | }
   | |_^
   |
   = note: #[warn(clippy::too_many_arguments)] on by default
   = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#too_many_arguments

warning: in an 'if' condition, avoid complex blocks or closures with blocks; instead, move the block or closure higher and bind it with a 'let'
  --> src/main.rs:86:26
   |
86 |               .map_err(|e| {
   |  __________________________^
87 | |                 ContextualError::IOError(
88 | |                     "Failed to retrieve symlink's metadata".to_string(),
89 | |                     e,
90 | |                 )
91 | |             })?
   | |_____________^
   |
   = note: #[warn(clippy::block_in_if_condition_stmt)] on by default
   = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#block_in_if_condition_stmt

    Finished dev [unoptimized + debuginfo] target(s) in 2.81s

Proposal

• Integrate clippy into CI
• Create a rls.toml that enables clippy

Is it possible to include as library with existing actix project? Would you be open to a PR making this possible?

Thanks!

Are you sure you want to leave this key visible to the public?

It would be nice to be able to sort the files differently. Currently, the ordering feels kind of wrong as the dirs are usually followed by the files but currently everything is only ordered alphabetically. It would be nice to get different order types. Maybe these order modes:

dirsfiles

dir1/
dir2/
dir3/
file1
file2
file3

alpha

A/
a
B
b/
C
c

natural

A/
B
C
a
b
c

Ticket: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=228324

Everything works perfectly fine 👍

I'll ping you once it is in the ports.

Cheers & happy hacking!

Example

miniserve --auth user1:password1 --auth user2:sha256:hash

Problem

miniserve already has an --auth feature, the problem is, the password is publicly visible. This makes it impossible to expose the command line to the public.

Solution

Support --auth username:sha256:password_hash syntax in addition to the old syntax.

P.S. I am trying to learn Rust by contributing to this repository, so don't implement this feature just yet.

Trying to download a file with spaces in its name from a served directory yields a 404 HTTP error. Reproducible via

$ touch "filename with spaces"
$ miniserve. &
$ wget http://localhost:8080/filename%20with%20spaces
--2019-01-03 01:33:52--  http://localhost:8080/filename%20with%20spaces
Resolving localhost (localhost)... ::1, 127.0.0.1
Connecting to localhost (localhost)|::1|:8080... connected.
HTTP request sent, awaiting response... 404 Not Found
2019-01-03 01:33:52 ERROR 404: Not Found.

File downloads without issue if that specific file is instead served, i.e. miniserve file\ with\ spaces.

Using miniserve v0.2.1.

Once you left the default theme, you can't get back into it using the link that's generated in the drop down as the link is wrong.

I am rather new to the Cargo build system but shouldn't there be a Cargo.lock file?

I guess it is not needed as it could be generated from Cargo.toml but it makes porting things much easier.

Cheers!

I'm actively using miniserve for something and realizing that I can't tell from the miniserve side that anything is happening. It'd be nice if, upon request, a log line was emitted, perhaps in Common Log Format.

host ident authuser date request status bytes

In src/errors.rs, I see ContextualError being a wrapper of ContextualErrorKind, is there a reason of this?

You are currently only allow Ipv4 access to the host, but no IPv6.
I would like to see either a command line argument to enable one/both or make dual stack the default :)

Originally posted by @svenstaro in #32

Just creating the issue so we can remember it. I'll probably do it after #32 is merged and #33 is done

The three release binaries are all for x86-64, but this is not specified anywhere. With the increasing prevalence of ARM-based systems even in the Windows world (e.g. various Snapdragon-based laptops) the releases page should at least list architecture (e.g., miniserve-linux-x86_64). Long-term, using a platform like trust on Travis to test and generate releases for multiple architectures seems wise.

Perhaps it would be cool for the host to see what's going on in a somewhat interactive interface.

Look into RFSAPI support.

• https://github.com/nabijaczleweli/rfsapi-rs
• https://github.com/thecoshman/doh

If you didn't enter the correct username or password, the browser will save them and send them to miniserver even when you force refresh the page. And you can't find anyway to logout.

The test logs does not show them before due to miniserve's logs being disabled by default. But now they are shown alongside normal test logs makes it hard to read the logs that actually matters.

Suggestion

Do not redirect stderr output of subprocess to parent's stderr.

P.S. I am not familiar with std::process so I am going to waiting for someone else to do it.

We have some places in the code where we call unwrap() (4 to be precise).

Maybe we could replace those with unwrap_or* (default value, actual error, etc, depending on the case) for unwrap()'s happening outside the main() method, and as for the ones happening in the main(), printing a nice error message with the logger + exiting instead of panicking.

This has been suggested in Reddit's "what's everyone working on this week": https://www.reddit.com/r/rust/comments/bapows/whats_everyone_working_on_this_week_152019/ekdt4ls

Build of miniserv 0.3.1 fails on all macOS versions (Homebrew/homebrew-core#38306) with:

   Compiling literalext v0.1.1
error[E0554]: #![feature] may not be used on the stable release channel
  --> /Users/brew/Library/Caches/Homebrew/cargo_cache/registry/src/github.com-1ecc6299db9ec823/literalext-0.1.1/src/lib.rs:19:37
   |
19 | #![cfg_attr(feature = "proc-macro", feature(proc_macro))]
   |                                     ^^^^^^^^^^^^^^^^^^^

error: aborting due to previous error

For more information about this error, try `rustc --explain E0554`.
error: Could not compile `literalext`.
warning: build failed, waiting for other jobs to finish...
error: failed to compile `miniserve v0.3.1 (/private/tmp/miniserve-20190326-39556-106jom/miniserve-0.3.1)`, intermediate artifacts can be found at `/private/tmp/miniserve-20190326-39556-106jom/miniserve-0.3.1/target`

Caused by:
  build failed

We already have -i as short flag. I suggest changing its long flag to --interface.

Currently, the default is entirely bleak. It would be nice to get a better looking file listing.

Currently I'm not super happy with how everything looks. It has a pale color palette without good contrast. It should have better contrast.

It shall be nice and time saver for many if precompiled binaries are available for ARM64/AARCH64 platforms.

I mean it would be handy for phones to access. Maybe a QR-code in the HTML page as well?

This is a single-binary-download server. A convenience option to serve its own binary might fit well.

Perhaps it could serve it under a name that includes appropriate target and version information, and have a 302 redirect from a simpler self URL?

It would be cool and convenient to be able to stream directories on the host as archives on the fly if you want to offer many individual files for download.

I have just submitted miniserve-bin to the AUR, you may want to include this in your README.md as an installation method (or not 😄 ).

I'm also willing to hear any update from you about new versions (so that I can update my AUR).

Most of the times I use miniserve it will cut the ends of files off. No idea what causes it but it happens regularly.

Miniserve version: 0.1.5
OS: Fedora 28