Warp: 0.2 Breaking Changes Tracking Issue

[seanmonstar]

Through usage of 0.1, some breaking changes have been found to be needed. This is to track that all are dealt with when 0.2 is released.

• [x] Replace get, post, put, and delete with the new get2, post2, put2, and delete2 filters.
• [x] Remove warp::cookie::optional_value.
• [x] Replace ws with ws2, Ws with Ws2.
• [x] Remove deprecated functions from reject module.
• [x] Remove Rejection::cause().
• [x] Remove warp::path::index.
• [ ] Add Transport bound to Server::serve_incoming and Server::run_incoming.

[dmexe]

Also path::param should be replaced with path::param2, it from 25e6c4e09c898c103c0da0a6ddecf8625bfa762e

[seanmonstar]

path::param2

I feel on the fence about it, personally. I could be convinced otherwise, but here's my thoughts:

• Most bad paths in servers are a 404.
• Creating a 404 rejection is cheap (it's basically an empty rejection set). Combing 404 rejections together is free. This allows a bunch of different path filters to be checked and reject and stay cheap.
• Creating a custom rejection in param2 means it can't be the empty rejection set. If there are multiple of them, they don't combine for free.

It is currently possibly to do what param2 does via param and and_then:

let route = warp::path::param::<String>()
    .and_then(|param_s| {
        param_s
            .parse::<MyParamThing>()
            .map_err(warp::reject::custom)
    })

[dmexe]

@seanmonstar I think we need a benchmark to see the performance penalty related to error handling.
I will do it this week.

[dmexe]

Benchmarks for param vs param2: https://gist.github.com/dmexe/f8c51065785d18926f3daaeacd9c3efb

Result

test filters::path::benches::bench_param  ... bench:          63 ns/iter (+/- 5)
test filters::path::benches::bench_param2 ... bench:         207 ns/iter (+/- 33)

param2 looks quite slowly in comparison to param

[seanmonstar]

Happening in https://github.com/seanmonstar/warp/compare/0.2.x?expand=1

[paulzhang5511]

@seanmonstar The api was broken, starting a new project, not knowing how to choose, when will the 0.2 version be released?

[Selicre]

Re: run_incoming - my current use-case for this framework is to run it behind a proxy so that I can easily restart the webserver without disrupting existing connections. I don't want to parse the HTTP traffic twice, so my solution was to just have the source IP be the first 4 bytes of the stream; however, it turned out that without editing the framework itself I couldn't actually set the source IP. It'd be really nice if it was possible to use a stream of i.e. (Option<SocketAddr>, impl AsyncRead+AsyncWrite) because the implementation is pretty much almost there, you just need to add an extra Option field to the LiftIo struct. I'm not sure if this needs an extra function, or if the existing one can be changed.

[seanmonstar]

Most of these have been merged into master, there should be an alpha this week.