directory tree support

[scottlamb]

Support serving a full directory tree from the local filesystem (and eventually also from data baked into the binary for easy release builds). Some things I'd like it to do:

• be fairly secure. At least avoid ..-style directory traversal attacks. Possibly an equivalent of nginx's disable_symlinks.
• MIME types. At least extension-based guessing (there's a mime_guess crate for this), preferably something pluggable.
• indefinite Expires headers for files with content-hashed filenames (see WebPack caching for example).
• directory listings, probably in a customizable way
• automatic gzip handling (if browser specifies Accept-Encoding: gzip, look for a file ending in .gz first and serve that with Content-Encoding: gzip)

I have a work in progress. It depends on nix-rust/nix#916.

[scottlamb]

I've finally committed a version of this on the dir branch. It works on Unix. Not on Windows (and I forgot to disable the feature in my .travis.yml there so the CI build is currently failing on that branch).

@lnicola is this a feature you're interested in working on Windows? You contributed the crate's initial Windows support in #10. I don't know how the Windows APIs compare. My Unix code opens the base directory's descriptor and uses libc::openat to find stuff within it. It also builds paths as C strings; I know Windows does some UTF-16 thing instead. And example/serve_dir.rs uses nix::dir which also wouldn't work so well.

[lnicola]

Sorry, I haven't looked into this yet (but I did notice the recent changes on its feature branch).

I don't think I need it. My use case is a server that does directory listings and archiving for download (as TAR currently, because they can be streamed, have a relatively predictable size and I didn't really need compression yet). But most of these seem like application, not library features, so I'd probably keep the same implementation.