issue #155

• Modify router! to take a string expr url instead of a token sequence.
  • Allows arbitrary routes with numbers/periods/non-token-types
• Url parameters must be specified in the url string and in a trailing identity: type pair.
• Update usage/tests and examples

problems:

• ~~Uses a HashMap when pulling url params out of the url string so it's definitely slower than the current implementation. (only routes with url params)~~
• ~~Still need to get multiple param parsing working e.g. (GET) ("/add/{a}/plus/{b}", a: u32, b: u32) .... The meat of the macro should work, but pattern matching that section is finicky and would likely require an ugly trailing separator for the no param variant: e.g. (GET) ("/home",) ...~~

Hello,

It looks like the application won't compile if the routes have hardcoded numbers in them. For example this works :

fn main() {
    println!("Listening!");

    rouille::start_server("0.0.0.0:8080", move |request| {

        router!(request, 
            (GET) (/) => {
                Response::text("Hello world!")
            },

            (GET) (/two) => {
                Response::text("Hello two!")
            },

            _ => Response::empty_404()
        )

    });
}

But this doesn't :

fn main() {
    rouille::start_server("0.0.0.0:8080", move |request| {

        router!(request, 
            (GET) (/) => {
                Response::text("Hello world!")
            },

            (GET) (/2) => {
                Response::text("Hello 2!")
            },

            _ => Response::empty_404()
        )

    });
}

It leads to the following error:

error: no rules expected the token `request_url`
  --> src/main.rs:11:9
   |
11 | /         router!(request,
12 | |             (GET) (/) => {
13 | |                 Response::text("Hello world!")
14 | |             },
...  |
20 | |             _ => Response::empty_404()
21 | |         )
   | |_________^
   |
   = note: this error originates in a macro outside of the current crate

error: Could not compile `rustit`.

Caused by:
  process didn't exit successfully: `rustc --crate-name rustit src/main.rs --crate-type bin --emit=
dep-info,link -C debuginfo=2 -C metadata=9a526171b8297007 -C extra-filename=-9a526171b8297007 --out
-dir /home/antoine/src/rust/rustit/target/debug/deps -L dependency=/home/antoine/src/rust/rustit/ta
rget/debug/deps --extern rouille=/home/antoine/src/rust/rustit/target/debug/deps/librouille-0f6c379
9a677a040.rlib -L native=/home/antoine/src/rust/Rustit/target/debug/build/brotli-sys-faf770ae9206b3
55/out -L native=/home/antoine/src/rust/Rustit/target/debug/build/miniz-sys-c9ca5bf082b97141/out` (
exit code: 101)

Is this normal behaviour? Is there anyway to get around this?

Serde is the replacement for rustc-serialize so add support for it under a feature flag so that users can continue to use rustc-serialize until they have migrated their code. fixes #149.

Related to #137, would it be possible to have a non-blocking variant of WebSocket::next? The idea would be the same as Receiver<T>::try_recv, it returns the next message if there is one ready, but returns without blocking if there are none. Without this functionality, it seems like it isn't possible to do something like have a thread wait for either a WebSocket or another channel.

I took a brief look at the implementation of WebSocket::next and it looks like its the underlying Box<ReadWrite>::read implementation that blocks waiting for data from the socket. Given that rouille is built on tiny_http, would it even be possible to implement a non-blocking read from the socket? Also, is it possible that I'm completely off-base in thinking that it's not possible to wait on both a WebSocket and another channel?

The pin for time =0.3.2, while helping you keep consistency on MSRV, unfortunately gets in the way of other crates that would like to depend on time ^0.3.5 for checked_add/checked_sub (which should really be used everywhere in preference over the panicky overloaded operators), but don't care that much about keeping their MSRV back.

I am at a point where i can use rouille for a basic web app, but whatever i try i can not get mysql to work. I keep getting errors after error, even though it works in other examples.

so what would be the best way to make rouille work with a database? Obviously the example isn’t good for me as it only handles one connection at a time.

Recent Rust version 1.39 marked the try! macro as deprecated. This patch replaces all usages of the try! macro with the recommended question mark operator.

This is a follow-up to #49

Once it's stable (https://github.com/rust-lang/rust/issues/35900), we can use the custom derive system for POST structs instead of using rustc-serialize.

This has the big advantage that we can adjust the corresponding trait to our needs, and make it work for files.

trait DecodePostField {
    fn from_field(content: &str) -> Result<Self, PostError>;
    fn from_file<R: BufRead>(file: R, mime: &str) -> Result<Self, PostError>;
}

trait DecodePostInput {
    fn decode<I: Iterator<Item = PostInputElement>>(elements: I) -> Result<Self, PostError>;
}

Example in practice:

#[derive(RouillePostDecode)]      // implements DecodePostInput on the struct
struct Input {
    field1: i32,         // each field must implement DecodePostField
    field2: String,
    file: TemporaryFileStorage,
}

let input: Input = try_or_400!(rouille::post::decode(&request));

If you read #49 I explain at the bottom that it isn't possible to do this. But if we use a trait other than the one in rustc-serialize, then it becomes a viable option.

In this example, the from_file method of TemporaryFileStorage would write the file to a temporary directory by streaming from the user's request, and then will return a TemporaryFileStorage struct that contains the path to the file. If the TemporaryFileStorage struct gets dropped before being stored in a database (for example because of a panic), its destructor would automatically delete the file.

Rouille could provide some helpers, like:

• TemporaryFileStorage
• BufferedFile (stores the content in memory)

There is one unresolved question, however: how do we provide a configuration for TemporaryFileStorage or BufferedFile? While these two cases don't need a configuration, it would be nice if we could write a S3File struct that automatically uploads to S3 or a ProxyFile that transfers the file to another service. But doing so requires some sort of configuration to be passed to from_file.

Summary

Added the Server::stoppable() function which provides a method for gracefully stopping a Server.

Motivation

There was obvious way to gracefully stop a Rouille server, and I ended up implementing this code in my own project. Since it's fairly simple and a useful feature I figured I would contribute it back.

See the provided documentation example for basic usage.

Hi

First off, thank you for creating Rouille, it's a wonderful library in a world of overcomplicated async frameworks.

Correlated to https://github.com/tiny-http/tiny-http/issues/199, I wondered if there were any plans to continue maintaining this crate? I've noticed some bugfix and compatible enhancement PRs have been open for over two years without further comment.

If you feel it's feature complete that's totally understandable, but if you would like some help responding to issues and PRs, or if you simply don't have time to remain involved with the project, then I'm ready to help.

Hello there!

With some time on my hands currently, I decided to fix some TODOs throughout the code base of Rouille.

Let me know what you think. :)

Cheers, Sven.

Replace the one call to num_cpus::get() with thread::available_parallelism() which has been stable since Rust 1.59 and has nearly identical functionality.

This allows for removing the dependency on num_cpus entirely.

Hello @tomaka @bradfier,

I added two simple macros, in similar fashion as start_server but with an extra local SSL context, so we can deploy an HTTPS server easily

If I want to be able to parse, say, std::net::Ipv4Addr I would have to:

• impl DecodePostField<()> for std::net::Ipv4Addr which is not possible
• I still can make a wrapper struct for which I'll implement it but it's still not possible because:
• there's no PostFieldError variant I can return in case things go wrong

How could I parse my own types ?

Handling requests from an upstream server, or tor, is a must! If the upstream server is local it becomes encumbering to use ports on a localhost interface for IPC. Enter Unix Domain Sockets.