Since I needed it to work with 2018 edition I've spend 10-15 minutes just porting it and at the end the async/await example also works!

I've just ran the cargo fix --edition and fixed one place where ::Error was left. The rest was just changing the example and the Cargo.toml of the project and the example.

Plus the features futures_api is not necessary any more.

Fixes https://github.com/carllerche/tower-web/issues/192#issuecomment-482449190

My context is evaluating replacements for Iron for the Rust Playground.

I've just skimmed hello_world so far. My raw thoughts are:

Why's all this code commented out?

How do I serve a file?

Ah, there's custom headers

How do I handle CORS?

Is there an overall vision for "features" and extensibility for tower-web? Do you want to farm things out to multiple crates, or have "most" / "common" things in one crate? Based on Tokio, I'm assuming many crates and perhaps re-export them in -web?

How do I return a Future from a method?

#[derive(Clone, Debug)]
pub struct SelfServing;

impl_web! {
    impl SelfServing {
        /// @get("/")
        /// @content_type("plain")
        fn x(&self) -> impl Future<Item = String, Error = ()> {

error[E0599]: no method named `run` found for type `tower_web::ServiceBuilder<SelfServing, _>` in the current scope
  --> examples/static_file.rs:37:10
   |
37 |         .run(&addr)
   |          ^^^
   |
   = note: the method `run` exists but the following trait bounds were not satisfied:
           `__IMPL_WEB_0_FOR_SelfServing::DispatchFuture<tower_web::response::DefaultSerializer, tower_web::run::LiftReqBody> : std::marker::Send`

Content type feels like it should be a property of the return type, but maybe optionally overridable by an attribute

I was looking into tower-web to integrate handlebars into its system.

The typical usage of handlebars in web application is to create a server-scoped registry, that holds all templates in memory. We use the registry to render templates returned from handler functions.

The ideal API for tower-web in my mind is to create a Template struct, which contains template name and template data. The Template struct will implement Response to render the data structure into actual http response. The problem is Response trait only provides a request-scoped Context so there seems to be no way to access server-scoped handlebars registry.

So is it possible to bind the registry into some data structure that has server-scoped lifetime? And be accessible from Response trait and middlewares.

• removes extern crate
• removes #[macro_use] attributes
• applies the modules system changes from 2018 edition, removing the mod.rs file

Opened questions:

• Should we update all the code (including docs) to use 2018 edition?

TODOs:

• ~Remove other extern crate + #[macro_use]~ Done

Maybe Resolves #37

In our applications we use JSON Web Tokens in authorization header and in some cases an access_token parameter in query string to authenticate user requests. Since some resources may allow an anonymous access, while other restrict it to users with particular permissions, we need a way to determine if token was presented in a request and if it's presented – validate and extract an information from it (for instance, sub claim in our tokens contains a user identifier).

Is there already any concept how it could be implemented?

I am exploring tower-web by writing a simple HTTP proxy. In this application, I would like to perform some header validation on each request, forward it to a pre-defined endpoint, and then forward the received response back to the original client. I am using a hyper::Client in each HTTP method handler to connect to the endpoint, but I am finding that I am duplicating the header validation code across each handler, which seems rather brittle to me. Is there a clean way to wrap a given type T where T implements IntoResource such that I can enforce this header validation for all incoming requests on all handlers in one place?

The user certainly wants this, and it helps with preventing directory traversal attacks.

~~The implementation supports arbitrary paths on Unix-like systems, and valid UTF-8 ones on Windows. I couldn't find a common way of percent-encoding Windows file paths, but this could potentially be improved in the future.~~

The implementation doesn't support non-UTF-8 paths.

Fixes #107.

E.g. I want to return either a File or an HTML page. I could probably make do with an enum that implements Response, but the File and String impls have different item types, so it's awkward.

Is there anything tower-web can do to make this easier?

You'd asked me to open an issue to discuss strategy, so here we go. There are basically two options. Ultimately the whole thing is getting passed to a derive, so the simplest option is to not have impl_web! spit out the tokens its given unmodified, and instead have derive_resource! spit out its input (with the recognized attributes stripped) in addition to what it spits out today.

You mentioned you had a solution which works and messes up error messages, so I'm assuming it's the solution above. The second option would be to run the tokens passed to impl_web! through another macro before outputting them. This would be a basic macro_rules! macro, which strips out regonized meta items.

Both of these options are pretty simple to implement. Diesel does both in multiple places (depending on whether our macro is fundamentally a macro_rules! or procedural macro). Would love to hear more about whether this would somehow affect your error messages.

Problem

When I cargo run the following I get a 500. That's all I know. Nothing else is displayed, no warnings, errors, hints, nothing.

Code

./src/main.rs:

#[macro_use]
extern crate tower_web;
extern crate tokio;

use tower_web::ServiceBuilder;
use tokio::prelude::*;

#[derive(Clone, Debug)]
struct Service;

#[derive(Response)]
struct IndexModel {
    title: &'static str,
}

impl_web! {
    impl Service {
        #[get("/")]
        #[content_type("html")]
        #[web(template = "index")]
        fn get_index(&self) -> Result<IndexModel, ()> {
            Ok(IndexModel {
                title: "hello world",
            })
        }
    }
}

pub fn main() {
    let addr = "127.0.0.1:8080".parse().expect("Invalid address");
    println!("Listening on http://{}", addr);

    ServiceBuilder::new()
        .resource(Service)
        .run(&addr)
        .unwrap();
}

./src/templates/index.hbs:

<html>
    <head>{{ title }}</head>
    <body>
        <div><h1>Winning!</h1></div>
    </body>
</html>

$ cargo run
   Compiling fieldmsg v0.1.0 (file:///Users/taryn/src/saas/fieldmsg)
warning: unused import: `tokio::prelude`
 --> src/main.rs:6:5
  |
6 | use tokio::prelude::*;
  |     ^^^^^^^^^^^^^^
  |
  = note: #[warn(unused_imports)] on by default

    Finished dev [unoptimized + debuginfo] target(s) in 3.12s
     Running `target/debug/fieldmsg`
Listening on http://127.0.0.1:8080

# in a different shell ...
$ http localhost:8080

HTTP/1.1 500 Internal Server Error
content-type: text/plain
date: Sun, 07 Oct 2018 12:15:01 GMT
transfer-encoding: chunked

internal server error

What am I supposed to do with this? How can I troubleshoot?

More info

$ cargo --version
cargo 1.29.0 (524a578d7 2018-08-05)
$ rustc --version
rustc 1.29.1 (b801ae664 2018-09-20)

[dependencies]
tower-web = "0.3.0"
tokio = "0.1.11"
serde = "1.0.79"

Edit:

I get the exact same result if I move templates/ to the root of the project (same dir as Cargo.toml).

As currently defined, BufStream produces a stream of Buf values, which in turn may contain multiple [u8] slices. I was curious what the tradeoffs were around, instead, having BufStream yield AsRef<[u8]> directly, thus "flattening" these two layers. I'm pretty sure there are straightforward ways to translate in either direction, but I may be missing something.

The examples fail to compile, could you fix? Steps to reproduce and error below.

git clone https://github.com/carllerche/tower-web.git
cd tower-web
cargo build --example hello_world

   Compiling tower-web-macros v0.3.5 (/tower-web/tower-web-macros)
warning: deny(rust_2018_idioms) is ignored unless specified at crate level
 --> tower-web-macros/src/lib.rs:2:8
  |
2 | #[deny(rust_2018_idioms)]
  |        ^^^^^^^^^^^^^^^^
  |
  = note: `#[warn(unused_attributes)]` on by default

warning: deny(rust_2018_idioms) is ignored unless specified at crate level
 --> tower-web-macros/src/lib.rs:2:8
  |
2 | #[deny(rust_2018_idioms)]
  |        ^^^^^^^^^^^^^^^^

error: unused extern crate
 --> tower-web-macros/src/lib.rs:4:1
  |
2 | / #[deny(rust_2018_idioms)]
3 | |
4 | | extern crate proc_macro;
  | | ^^^^^^^^^^^^^^^^^^^^^^^-
  | |________________________|
  |                          help: remove it
  |
note: the lint level is defined here
 --> tower-web-macros/src/lib.rs:2:8
  |
2 | #[deny(rust_2018_idioms)]
  |        ^^^^^^^^^^^^^^^^
  = note: `#[deny(unused_extern_crates)]` implied by `#[deny(rust_2018_idioms)]`

error: aborting due to previous error; 2 warnings emitted

error: could not compile `tower-web-macros`

OS: MacOS Big Sur 11.3.1 tower-web version: the latest one rustc 1.51.0 (2fd73fabe 2021-03-23) cargo 1.51.0 (43b129a20 2021-03-16)

Hi, can you please add in the README here (and early on in the API docs website) what specifically to add to your Cargo.toml file to make the "hello world" example code work? 🙏

Thanks!

Hi,

I'm leading a benchmarking project => https://github.com/the-benchmarker/web-frameworks

The purpose of this project is to compare performances (other indicators will come), based on a fairest, as we can, comparison for rust frameworks (comparing on the same version, for example).

Do you mind that I (or any member) add tower-web ? :heart:

Regards,

This is a relatively basic app that just listens to a HTTP POST request, to which I'm sending around ~2GB of data.

The framework seems to spends around 9 seconds copying data around, and around 6 seconds in generated code (the _IMPL_WEB_0 stuff).

This is on Windows, reasonably fast machine (i9, 16G of ram etc), copying the same file around in explorer takes round 2-3 seconds.