Similar to @Urhengulas' PR #741, although more complete, this PR aims to upgrade to Tokio v1.0.

I can successfully run all tests with all features enabled: cargo test --all-features.

This is my first time trying to contribute to warp, and I'm not super familiar with the internals, so please consider it a best effort :)

Fixes #725.

Dependencies which need to upgrade

• [x] hyper (hyperium/hyper#2369)
• [x] tokio-rustls (tokio-rs/tls#46)
• [x] tokio-tungstenite (snapview/tokio-tungstenite#142)

Hi.

I have been testing warp and nginx with a minimal content (just a "hello world" message) and noticed warp is very slow, but I'm not sure if the slowness is related to warp or something I'm doing wrong.

The nginx config and content:

nginx -v

nginx version: nginx/1.16.1

cat /etc/nginx/nginx.conf

worker_processes auto;
worker_cpu_affinity auto;
events {
    worker_connections  10000;
}
http {
    access_log off;
    keepalive_timeout 65;
    server {
        listen 8080 default_server;
...

cat /usr/share/nginx/html/index.html
Hello World

curl -v http://localhost:8080
*   Trying ::1:8080...
* TCP_NODELAY set
* connect to ::1 port 8080 failed: Connection refused
*   Trying 127.0.0.1:8080...
* TCP_NODELAY set
* Connected to localhost (127.0.0.1) port 8080 (#0)
> GET / HTTP/1.1
> Host: localhost:8080
> User-Agent: curl/7.65.3
> Accept: */*
> 
* Mark bundle as not supporting multiuse
< HTTP/1.1 200 OK
< Server: nginx/1.16.1
< Date: Thu, 30 Apr 2020 22:43:42 GMT
< Content-Type: text/html
< Content-Length: 12
< Last-Modified: Thu, 30 Apr 2020 21:16:45 GMT
< Connection: keep-alive
< ETag: "5eab403d-c"
< Accept-Ranges: bytes
< 
Hello World
* Connection #0 to host localhost left intact

The warp stuff:

rustc --version
rustc 1.43.0-nightly (2890b37b8 2020-03-06)

cat examples/hello.rs 
#![deny(warnings)]
use warp::Filter;

#[tokio::main]
async fn main() {
    let routes = warp::any().map(|| "Hello World");
    warp::serve(routes).run(([0, 0, 0, 0], 8080)).await;
}

cargo build --release

sudo ./target/release/examples/hello
# using sudo just to get all kernel configurations

curl -v http://localhost:8080
*   Trying ::1:8080...
* TCP_NODELAY set
* connect to ::1 port 8080 failed: Connection refused
*   Trying 127.0.0.1:8080...
* TCP_NODELAY set
* Connected to localhost (127.0.0.1) port 8080 (#0)
> GET / HTTP/1.1
> Host: localhost:8080
> User-Agent: curl/7.65.3
> Accept: */*
> 
* Mark bundle as not supporting multiuse
< HTTP/1.1 200 OK
< content-type: text/plain; charset=utf-8
< content-length: 11
< date: Thu, 30 Apr 2020 22:43:13 GMT
< 
* Connection #0 to host localhost left intact

Environment

lscpu

Architecture:        x86_64
CPU op-mode(s):      32-bit, 64-bit
Byte Order:          Little Endian
Address sizes:       43 bits physical, 48 bits virtual
CPU(s):              8
On-line CPU(s) list: 0-7
Thread(s) per core:  2
Core(s) per socket:  4
Socket(s):           1
NUMA node(s):        1
Vendor ID:           AuthenticAMD
CPU family:          23
Model:               24
Model name:          AMD Ryzen 7 3700U with Radeon Vega Mobile Gfx
Stepping:            1
CPU MHz:             1295.685
CPU max MHz:         2300.0000
CPU min MHz:         1400.0000
BogoMIPS:            4591.23
Virtualization:      AMD-V
L1d cache:           32K
L1i cache:           64K
L2 cache:            512K
L3 cache:            4096K
NUMA node0 CPU(s):   0-7
Flags:               fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm constant_tsc rep_good nopl nonstop_tsc cpuid extd_apicid aperfmperf pni pclmulqdq monitor ssse3 fma cx16 sse4_1 sse4_2 movbe popcnt aes xsave avx f16c rdrand lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw skinit wdt tce topoext perfctr_core perfctr_nb bpext perfctr_llc mwaitx cpb hw_pstate sme ssbd sev ibpb vmmcall fsgsbase bmi1 avx2 smep bmi2 rdseed adx smap clflushopt sha_ni xsaveopt xsavec xgetbv1 xsaves clzero irperf xsaveerptr arat npt lbrv svm_lock nrip_save tsc_scale vmcb_clean flushbyasid decodeassists pausefilter pfthreshold avic v_vmsave_vmload vgif overflow_recov succor smca

lsb_release -a

LSB Version: core-4.1-amd64:core-4.1-noarch
Distributor ID: Fedora
Description: Fedora release 30 (Thirty)
Release: 30
Codename: Thirty

Finally, the tests using wrk!

wrk results (avg, after three intervaled tests) for nginx

./wrk -t10 -c1000 -d10s --latency http://127.0.0.1:8080/
Running 10s test @ http://127.0.0.1:8080/
  10 threads and 1000 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency    14.48ms   16.27ms 285.61ms   90.53%
    Req/Sec     8.12k     1.59k   15.99k    78.23%
  Latency Distribution
     50%   10.07ms
     75%   16.66ms
     90%   29.94ms
     99%   72.74ms
  807992 requests in 10.10s, 190.29MB read
Requests/sec:  79976.39
Transfer/sec:     18.84MB

wrk results (avg) for warp

./wrk -t10 -c1000 -d10s --latency http://127.0.0.1:8080/
Running 10s test @ http://127.0.0.1:8080/
  10 threads and 1000 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency    32.43ms    2.92ms  41.16ms   70.49%
    Req/Sec     3.08k   325.14     3.97k    72.20%
  Latency Distribution
     50%   32.07ms
     75%   34.20ms
     90%   36.97ms
     99%   39.35ms
  306502 requests in 10.06s, 37.41MB read
Requests/sec:  30474.16
Transfer/sec:      3.72MB

(using wrk compiled by sources on Fedora30 with Clang 8.0)

Notice warp is about three times slower than nginx.

P.S. 1.: I did more tests using ApacheBench and JMeter with five machines (clients) connected to an external server remotely (with some limits due to internet bandwidth) providing a larger content (around 150 kB), but got slower results in warp again. 😕

P.S. 2: Notice the nginx.conf on top of this message. How to apply those configs in warp? (specially worker_processes, worker_cpu_affinity and worker_connections).

Why?

I don't know if there is any specific configuration to increase the warp speed. I would appreciate it and retest to get better results.

TIA for any help!

Every day something new. Today I discovered the "trailing slash" dilemma. I use Warp to reply dynamic content:

warp::path!("cargo_crev_web" / "info" ).map(|| {
        let info_data = proof_index_mod::InfoData::new();
        let html_file = info_data.render_html_file("templates/");
        warp::reply::html(html_file)

This 2 routes seems the same: https://bestia.dev/cargo_crev_web/info/ https://bestia.dev/cargo_crev_web/info But unfortunately there are some subtle (unpredictable) differences. On the page there is a relative link:

<div><a style="color:white" href="group_by_crate">group by crate</a></div>

So if you click on the link "group by crate" there is a difference how the relative routes are calculated. With the first route with trailing slash, the link is correct: https://bestia.dev/cargo_crev_web/info/group_by_crate The relative link is added. This is what I want. But with the second link without trailing slashes, the link is invalid: https://bestia.dev/cargo_crev_web/group_by_crate The /info/ part is completely missing. It was a surprise to me. Not a good one. The recommended thing to do is a redirect from without slash to trailing slash. Do you have some experience how to solve this in Warp?

I get the impression that the rejection system in this crate ought to be severely refactored. The rejections example does not show a simple way of handling functions which return Results:

async fn login(credentials: Credentials) -> Result<UserSession, LoginError> {
    ...
}

which is the standard way of handling Errors in Rust. The suggested way of handling this seems to be to

• implement Reject for LoginError (which requires me to own the LoginError type)
• call recover after the handling filter with a "rejection handler" function, which converts rejections into a Reply type which can be sent by warp

This causes a lot of cognitive and syntactic overhead, and I think the crate would benefit a lot from a refactor like this.

Tracing enables us to keep track of some contextual state throughout the lifetime of a request. This means that any logging done when processing a request will automatically also log the context. This is especially useful when processing requests in parallel because it means that one can separate intertwined logs.

The author of tracing made a good and informative video about the subject, and showing off some of the benefits.

This is based upon @emschwartz issue and his previous work.

This is mainly a rough first implementation to see if you would like this feature. If you are interested in this feature I was planning to go through all uses of log in the crate to replace with appropriate span's and event's. What do you think @seanmonstar ?

Closes #288

Tipping point for me to jump into Future type hell to implement this was this comment - but I'd say it's worth it. I've used it in my personal project for a while, and the code I've been able to write is much cleaner, I think.

Changes:

• Added Filter::then() and complementary type Then. Exactly like map, but async. The name is meant to reflect future's then() function.
• Filter::and_then() documentation now points to Filter::then() as an alternative, since my understanding is that:

  Rejections are meant to say "this filter didn't accept the request, maybe another can."

Fix #712 Fix #594

Providing Reply implementations for Result would also be very useful, so this is loosely related to #458

Post-edit note: This function was renamed from map_async to then to more closely match future's api. However it is worth noting that just as Filter::map isn't exactly like future's map on account of rejections, Filter::then isn't exactly like future's then. However Filter::then is the same, conceptually, as future's then, so this seems like the best choice.

It would be nice to include some built-in filters in warp::multipart (or warp::body?). I'm not sure what the API should look like. Some things that come to mind that a user could want to do:

• Decode a multipart body via serde::Deserialize.
• Receive a file upload.
• Receive multiple file uploads.
• Allow streaming of the data, since buffering an entire file upload in memory could be bad if the files are huge.

Under the current api, Filter::with requires that the type be W: Wrap however the Wrap trait is sealed making it difficult to write custom wrapping filters. For instance, I'm trying to write a filter that will forward a header from a request to the response. So far I've come up with the filter to generate the either grab the request id or generate a new one:

let req_id = warp::header::<String>("x-request-id").or_else(|_| Ok(("generated".to_owned(),)))

But I can't figure out using the combinators provided how to store the request-id in the filter and use it on the response.

It also seems that you cannot call map after returning a warp::reply in the combinator chain so I can't even make the above work with boiler plate something like

let my_route = req_id.map(warp::reply).map(|id: String, reply: warp::Reply| {
    reply.set_header("x-request-id", id)
})

I'm seeing compile times on the order of minutes for a small < 10 route service.

    Finished dev [unoptimized + debuginfo] target(s) in 3m 12s
     Running `target/debug/mtbox-warp-admin`

What are some things that I could look for to help shrink this to something more manageable?

In Framework Benchmarks, warp 0.2 is very very slow (check for entry called warp-rust): https://www.techempower.com/benchmarks/#section=test&runid=7f65c127-fad2-4a88-a6cb-5333c68362ef&hw=ph&test=plaintext

This isn't the issue with warp 0.1 (again, check for entry called warp-rust): https://www.techempower.com/benchmarks/#section=test&runid=d13756ac-4638-4c62-b1b4-cde1fd47a72a&hw=ph&test=plaintext

250,000 performance score seems much worse than 1,800,000. PHP running with php-fpm and nginx is faster than warp 0.2. It may be worth looking into why, because that's really unexpected.

Benchmark code: https://github.com/TechEmpower/FrameworkBenchmarks/blob/master/frameworks/Rust/warp-rust/src/main.rs

I just tried to rebase #909 and CI failed.

I tested again with nightly-2022-09-27 and the tests passed, but the master branch fails cargo test with current nightly.

Seems some of the examples/tests are now errors (correctly so, at least at first glance).

The present PR improves the performance of Rejections::into_response(). Compared to the original approach it calls status only for known or custom instances, which allows to avoid exponential complexity. A test is added to check that the response is computed in a reasonable time, with the original implementation the test fails to complete in 1 minute.

Is your feature request related to a problem? Please describe. i keep geting errors that error converting to string with no context as to why it couldent.

Describe the solution you'd like instead of returning Result<&str, ()> return Result<&str, impl std::error::Error>

Describe alternatives you've considered n/a

Additional context i see from scrolling through the src code that its prob because my data is not of type String but ether way a error type of () is not acceptible.

Version warp = {version = "0.3.3", features = ["tls"]}

Platform macOS 12.5

Description I am trying to setup dual TLS for warp, however the TLS handshake fails on client authorization.

Code snippet:

    async fn handler() -> Result<impl Reply, Rejection> {
        Ok("success".to_string())
    }

    #[tokio::main]
    pub async fn web_service() {
        let metrics_route = warp::path("metrics").and(warp::get()).and(warp::path::end()).and_then(handler);
        warp::serve(metrics_route)
            .tls()
            .cert_path("server/cert.pem")
            .key_path("server/rsaprivkey.pem")
            .client_auth_required_path("client/cert.pem")
            .run(([0, 0, 0, 0], 9100)).await;
    }

Private keys and certificate generation (separately in client and server folders):

openssl genrsa -out rsaprivkey.pem 2048
openssl pkcs8 -topk8 -inform PEM -outform PEM -in rsaprivkey.pem -out rsaprivkey8.pem -nocrypt
openssl req -new -x509 -key rsaprivkey8.pem -out cert.pem
rm rsaprivkey.pem 
mv rsaprivkey8.pem rsaprivkey.pem 

To test:

1. start web_service
2. in terminal: run openssl s_client -connect localhost:9100 -cert client/cert.pem -key client/rsaprivkey.pem -CAfile server/cert.pem -debug output:

***
4377953664:error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert handshake failure:ssl/record/rec_layer_s3.c:1544:SSL alert number 40

OR

run curl -k -iv --cert client/cert.pem --key client/rsaprivkey.pem --cacert server/cert.pem https://localhost:9100 output:

*   Trying 127.0.0.1:9100...
* Connected to localhost (127.0.0.1) port 9100 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*  CAfile: server/cert.pem
*  CApath: none
* (304) (OUT), TLS handshake, Client hello (1):
* (304) (IN), TLS handshake, Server hello (2):
* (304) (IN), TLS handshake, Unknown (8):
* (304) (IN), TLS handshake, Request CERT (13):
* (304) (IN), TLS handshake, Certificate (11):
* (304) (IN), TLS handshake, CERT verify (15):
* (304) (IN), TLS handshake, Finished (20):
* (304) (OUT), TLS handshake, Certificate (11):
* (304) (OUT), TLS handshake, CERT verify (15):
* (304) (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / AEAD-CHACHA20-POLY1305-SHA256
* ALPN, server accepted to use h2
* Server certificate:
*  subject: C=AU; ST=Some-State; O=Internet Widgits Pty Ltd
*  start date: Nov  8 08:38:26 2022 GMT
*  expire date: Dec  8 08:38:26 2022 GMT
*  issuer: C=AU; ST=Some-State; O=Internet Widgits Pty Ltd
*  SSL certificate verify ok.
* Using HTTP2, server supports multiplexing
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* Using Stream ID: 1 (easy handle 0x140014000)
> GET / HTTP/2
> Host: localhost:9100
> user-agent: curl/7.79.1
> accept: */*
> 
* LibreSSL SSL_read: error:1404C410:SSL routines:ST_OK:sslv3 alert handshake failure, errno 0
* Failed receiving HTTP2 data
* LibreSSL SSL_write: SSL_ERROR_SYSCALL, errno 0
* Failed sending HTTP2 data
* Connection #0 to host localhost left intact
curl: (56) LibreSSL SSL_read: error:1404C410:SSL routines:ST_OK:sslv3 alert handshake failure, errno 0

Everything works fine when I disable client authentication. It may be that I misunderstand the way dual TLS should be used, but I spent a lot of time trying to make this work (including different ways and types of ssl keys and certificates)