3 ms·
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 po
by pornel 5y ago
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).
- the_duke 5y agoNone 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.
- pornel 5y agoSlow 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.
- orf 5y agoIf 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.