On your blog, you say that some important features are on the roadmap, including async static file serving. Is there any work on that for the moment ?

/// # customize response for HandlerError /// ## Why do we need it? /// We might want to customize different response for different error, eg: /// * for authorized-user-resource, we might return 403(Forbidden) for an un-logged-in user; /// * or when some file user requesting is not found, we might return 404; /// * ... /// Or we just want to send with content-type: application/json when request is application/json. /// (In the old, we just send 500 with plain/text for any request if error happens)

This refactors the service implementation a little bit to instantiate the State via a dedicated method. The underlying goal is to allow users to use Gotham without having to use its handler.

The motivation for this is to let users inject more things into their state and call their handler directly instead of having to go through a Hyper service. In our case, we use this for:

• Integrating in a Hyper service for a sub-route.
• Injecting data about TLS client certificates that were used by the client

With the anticipated release of async-await in stable rust this week, I took an effort to migrate Gotham to run on std futures using the pre-release versions of the dependencies (tokio, hyper, etc).

NOTE: This doesn't attempt to introduce await or async fn into the codebase (there was a single unavoidable case due to an tokio::File::metadata API change). That is designed as a future activity.

This migration involved a few key efforts:

1. Convert from Futures 0.1 to Futures-preview 0.3 (mostly Future<Item=> to Future<Output=Result<>>).
2. Update dependencies to pre-release versions (tokio-0.2 and hyper-0.13). There's still other dependencies that are outstanding and blocking the full release.
3. Migrate Handler trait to a pinned box HandlerFuture.

This is a work-in-progress with a few blockers before this would be ready:

Gotham Dependencies:

• [x] Update Futures from futures-preview to futures = 0.3 when the other dependencies (hyper, tokio, etc) update in concert.
• [x] Update Tokio to 0.2 from alpha pre-releases
• [x] Update Hyper to 0.13 from alpha pre-releases
• [x] Update Tower-Service to 0.3 from alpha pre-releases. Hyper is migrating many of its traits to tower-service::Service and so is now a direct dependency.
• [x] Released version of futures_rustls which is currently a branch of tokio-rustls ported to Futures-preview
• [x] Released version of futures-tokio-compat or suggested tokio::compat library for bridging futures::AsyncRead and tokio::AsyncRead. See https://github.com/tokio-rs/tokio/issues/1297 and https://github.com/async-rs/async-std/issues/54

Middleware Dependencies:

• [x] Diesel - Requires updated release of tokio-threadpool
• [ ] JWT - Requires updated release of jsonwebtoken since it's dependency ring conflicts withs futures-rustls.

The following examples were not updated (and thus commented out in Cargo.toml) due to incompatible dependencies:

• [x] hello_world_until is dependent on a compatible version of tokio-signal
• [x] diesel is dependent on the Diesel middleware
• [ ] openssl is dependent on tokio-openssl
• [ ] websocket is dependent on tokio-tungstenite

This is a first attempt at building the Router creation API that will be used by all Gotham applications.

The primary goal of this branch is to get as far as we can without introducing any macros. Keeping in line with idiomatic Rust, I opted to write a "builder" API for the router. An simple example router with this API looks like:

fn router() -> Router {
    // Note: Pipeline API isn't part of this PR
    let pipelines = new_pipeline_set();
    let (pipelines, default) =
        pipelines.add(new_pipeline().add(NewSessionMiddleware::default()).build());
    let pipelines = finalize_pipeline_set(pipelines);
    let default_pipeline_chain = (default, ());

    // Router builder starts here
    build_router(default_pipeline_chain, pipelines, |route| {
        route.get("/").to(welcome::index);

        route.get("/dashboard").to(dashboard::index);

        route.scope("/api", |route| {
            route.post("/submit").to(api::submit);
        });
    })
}

More in-depth examples:

• The kitchen-sink example app has been updated to use this API
• Test case in gotham::router::builder
• Documentation available by running cargo doc --features experimental-router on this branch

This is an experimental API which will likely see some breaking changes before we're totally happy with it, ~~and so it will ship behind a Cargo feature ("experimental-router") to communicate that fact to app developers who might otherwise expect some stability in the API.~~

As a future concern, once this API is bedded in and we know more about what we can't do with a builder API, we can look at adding macros. That's out of scope for this PR.

Comments/questions/feedback/review welcome from anybody who's interested in doing so.

This fixes #277, kinda.

This PR will introduce some new constructs for returning responses, namely:

Into<Body>
(Mime, Into<Body>)
(StatusCode, Mime, Into<Body>)

There are a few things to note:

• We can't actually implement for Into<Body> due to clashes with Response<Body>, so they're manually derived for the meantime (somewhat annoying, but not the end of the world).
• The default mime type is TEXT_PLAIN; not sure if it should be something else?
• The default status code is OK.

Each implementation just passes through to the next, and the actual response is built using the create_response function in the helper - to keep things consistent. I adjusted the signature there to align with the new types as well.

The idea is that create_response is now only needed when you need to do something to the response itself manually; such as changing headers, and so on. If you only care about status/mime/body, you can just return a Tuple (which should theoretically work for a lot of cases).

In doing all of this, the generic type B was removed from IntoResponse - which isn't breaking as it was introduced between 0.2.1 and now anyway. I think aligning on Body for the response body type makes sense at least for the time being.

Finally I removed construct_response in favour of making create_empty_response the base response creator. I doubt there's much overhead to doing it this way, and even so it makes the code more readable so likely a non-issue.

A few remaining questions I'd like opinions on:

1. Given that the point of this is to discourage create_response directly, should I update all examples to use these new formats?
2. Should create_response simply become a function that accepts State, IntoResponse? It can then just attach any default headers (etc.) onto the returned response.
3. Is TEXT_PLAIN an appropriate default mime type?

The best (read: laziest) way to describe this PR is by pointing at the documentation for the "workers" and "diesel" middleware as written for this PR (mostly the rustdoc).

Ref #210

I would like to run two tokio-based servers in parallel in my application, one of which is a Gotham HTTP server. As far as my understanding of tokio goes, it ought to be possible to create one event loop and register both services onto it.

Is there a way to start a Gotham server using a provided tokio Handle, rather than letting it create its own event loop? If not, and you feel that its a reasonable feature to implement, I'm happy to work on adding this behaviour.

Hi, I want to write code like this:

fn homepage(state: State) -> search::Result<(State, Response<Body>)> {
    let a = expr()?
    return (state, a);
}

fn make_router() -> search::Result<Router> {
    let state = IndexState::new()?;
    let middleware = StateMiddleware::new(state);
    let pipeline = single_middleware(middleware);
    let (chain, pipelines) = single_pipeline(pipeline);
    Ok(build_router(chain, pipelines, |route| {
        route.get("/").to(homepage); // FIXME! doesnt work!
    }))
}

But the IntoHandlerFuture trait does not get auto-impld for homepage. Therefore, I cant use ? in my function body.

I tried adding the following into gotham:

impl<T: IntoHandlerFuture, E: IntoHandlerFuture> IntoHandlerFuture for std::result::Result<T, E> {
    fn into_handler_future(self) -> Pin<Box<HandlerFuture>> {
        match self {
            Ok(hf) => hf.into_handler_future(),
            Err(hf) => hf.into_handler_future(),
        }
    }
}

But I cant impl IntoHandlerFuture for my Error type:

impl IntoHandlerFuture for Error {
    fn into_handler_future(self) -> Pin<Box<HandlerFuture>> {
        future::ok((NO_STATE_AVAILABLE_HERE, response)).boxed()
    }
}

But there was no way to get the state to return in into_handler_future.

So I ask, can the API be changed to allow such code? Thank you.

The current "under development" Diesel middleware provides a "blocking" api to use Diesel. Some previous work was done (and abandoned) to provide a worker CpuPool middleware to allow not blocking request handling when using diesel.

I have been experimenting with continuing this, but with a different approach. Although Diesel doesn't directly support async, we can still build an async application around it using tokio_threadpool::blocking. This removes the need to explicitly manage a separate CpuPool, and looks like it will be a simpler implementation and api.

I'm opening this issue to solicit discussion around this approach and coordinate efforts in pushing Diesel support forward. The new experimental api so far provides a repo abstraction that handles the DB connection pool and wraps tokio_threadpool::blocking. Usage looks something like:

    let repo = Repo::borrow_from(&state);
    let user = .....;
    // Returns a future able to be chained into a `HandlerFuture`
    repo.run(move |conn| {
        diesel::insert_into(users::table)
            .values(&user)
            .get_result(&conn)
    }) 

Previous work this would supersede includes: https://github.com/gotham-rs/gotham/pull/227 https://github.com/gotham-rs/gotham/issues/77 https://github.com/gotham-rs/gotham/pull/126

The rand crate recently split code pertaining to the ChaCha implementation into its own crate. This PR changes Gotham to include that new dependency, and updates the core rand crate to version 0.6.

The problem

I was looking for a way to change the status code of my response and it has been hard to find to me, I based on the next example to create a CORS middleware, but the response status code was always 200 code, instead of 401 (unauthorized), so I had to change the status code manually, but I don't find any way to change it properly.

https://github.com/gotham-rs/gotham/blob/84c7f08b06608c06abffc60d4ad797060173a3d8/examples/middleware/introduction/src/main.rs#L75-L92

I also tried to base on this documentation to change the status code, but that doesn't work with my problem, since this example instead of modifying an existing response is creating a new empty response.

https://github.com/gotham-rs/gotham/blob/84c7f08b06608c06abffc60d4ad797060173a3d8/examples/middleware/introduction_await/src/main.rs#L100-L112

Then I noticed the status_mut function in the response struct, but it doesn't have any documentation about how to use it. So I couldn't use it anyway. Later I checked and found this block of code in this GitHub repository and I based on it to change the response status code, and that worked properly. But I think it could be included in the examples, for example, the first one that I mentioned could include this part about how to change the status code

https://github.com/gotham-rs/gotham/blob/7251955067832131bce80de7662749976957ded5/gotham_derive/src/extenders.rs#L15-L19

The request

I suggest to add examples about how to use status_mut() to the middleware examples or to another example where it was visible so beginners can easily change the status_mut of a response

URLs with and without trailing slashes are considered to be different. Serving the same content behind a URL with and without a trailing slash may be considered duplicate content by search engines.

There should be a way to redirect all URLs (via 301 Moved Permanently) to their canonical equivalent. That includes removing empty segments as well as redirecting to the variant with or without trailing slash (that should be selectable – I prefer trailing slashes, because I can then easily add subpages later).

EDIT: Trailing slashes should not be added if a file is accessed, so this seems to be more complicated after all. One can also consider interpreting . and .., this might even be necessary if HTML pages use relative URLs (like <img src="../images/1.jpg">), but I don’t know to what extent browsers are already required to resolve this before sending the request.

Updates the requirements on cookie to permit the latest version.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

Hi! I'm working with futures (i.e my handlers are async)

Ofter I need to protect my Service around Arc<Mutex<_>> where Arc and Mutex came from std. But when you are working with futures, it's better to use futures::lock::Mutex in order to avoid dead lock (see for example https://users.rust-lang.org/t/std-mutex-vs-futures-mutex-vs-futures-lock-mutex-for-async/41710/2) So,

use futures::lock::Mutex;
use std::sync::{Arc};

#[derive(Clone, StateData)]
pub struct ChatServiceWrapper {
    pub inner: Arc<Mutex<ChatService>>,
}

    let chat_service = ChatServiceWrapper {
        inner: Arc::new(Mutex::new(ChatService::new())),
    };
    let pipeline = new_pipeline()
        .add(StateMiddleware::new(chat_service)) // <--- this goes to error
        .build()

the error is

the type `std::cell::UnsafeCell<chat_service::ChatService>` may contain interior mutability and a reference may not be safely transferrable across a catch_unwind boundary

`std::cell::UnsafeCell<chat_service::ChatService>` may contain interior mutability and a reference may not be safely transferrable across a catch_unwind boundary

help: within `rest_api::ChatServiceWrapper`, the trait `std::panic::RefUnwindSafe` is not implemented for `std::cell::UnsafeCell<chat_service::ChatService>`

How can I fix this error??

Thanks a lot

Maybe this should be done different, but I would assume that I can additionally to modify the status_code of the HandlerError also add body data. My use-case would be e.g.: parsing JSON data from the request and if there is a syntax error return the error message from serde(as body) with an UNPROCESSABLE_ENTITY status code.

Currently, all handler functions take either State or &State as their only parameter, and need to retrieve all information they need in user code. It would be more convenient if we allowed for syntax like this:

route.get("/").to(|(headers, body): (HeaderMap, Body)| { /* create response */ })

This was first suggested by @tanriol in the Gitter chat.