Because of the way Rust's async works, you can put a timeout on anything (e.g. you don't need your http parser support timeouts, you can kill it at any await point). So it's only a matter of choosing timeout policy for your app. One person's DoS attack is another person's long polling API.

Anyway, it has nothing to do with Serde, which doesn't have a network component. For Serde you'd typically buffer the input first, or use external framing (like line-oriented JSON).

None of the current Rust async frameworks will prevent your synchronous code from going haywire.

Tokio or async-std timeouts only cancel futures. The dedicated spawn_blocking threadpools also do not support cancellation.

To prevent such cases you would have to spawn the work into a dedicated thread pool and then kill the thread on timeout.

Terminating threads is a very complicated topic though and not generally possible for compiled languages, especially without introducing memory unsafety.

The only real workaround is to have the synchronous code regularly check for cancellation via an atomic bool or similar, and terminate if required.

Slow loris is I/O based, so it’s easy to abort. The rest will follow from that. Even if you piped your request stream into synchronous blocking io::Read adapter for use with Serde (which IMHO is pointless), the adapter will see an error due to its channel dropping, and bail out immediately.

Native busy-looping or deadlocked threads are tricky to kill safely, but that’s a general problem with threads in non-interpreted languages. Not specific to Serde, not related to Slow loris.

If you’re blocking on IO that’s you’re cancellation signal. You can of course close the pipe you’re reading from which surfaces an error in your synchronous thread.

How is that related to serde?

I thought I'd share this project in case anyone wanted to quickly evaluate rust for web

https://github.com/wulf/create-rust-app

Although there's a lot of work left to be done, I'd love to hear feedback, painpoints and ideas you have :)

Hoping to have documentation up at create-rust-app.dev soon~

Please consider giving warp as choice for the web server.

Any particular reason?

Its more light weight and usually doesn't enforce any particular way of doing things. Regardless of warp support, I have most of the other things on your list integrated one by one (JWT/dashboards /react/diesel) but it was time consuming as I didn't have a quick start project template.

So I think the work you are doing is going to be valuable for the community. I guess giving an option between the three popular web frameworks (actix, warp, rocket) won't be so easy as you might have very different way of integrating the authentication etc with each. Probably one way to do this is to keep things more modular so that the authentication can be called independently (among other features).

This is interesting, and news to me. Your comment suggests something about Rust imposes this problem on all web frameworks, is that true? If so could you share the root cause?

I'm just newbie in Rust. Does some web framework not use hyper? I'm trying to find web framework that does not have problem with Slow-Loris.

This doesn't solve your problem out of the box, but I think most reverse-proxies have configurations that can protect the services behind them from these sorts of attacks.

I don't think anyone will want to avoid hyper, tbh, that's a lot of work to hand-roll instead. so you better advertise the issue there instead, and if they refuse to do anything about it then make a big stink downstream.

I think this should be fixed in hyper.