6 ms·

Is there any Rust web framework that does not have problem with Slow-Loris ? https://github.com/SergioBenitez/Rocket/issues/1405 https://github.com/SergioBenit

• eptcyka 5y ago
  I think this should be fixed in hyper.
• ttymck 5y ago
  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?
  • xet7 5y ago
    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.
    • Ericson2314 5y ago
      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.
    • fwip 5y ago
      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.
• 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 ago
    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.
    • pornel 5y ago
      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.
    • orf 5y ago
      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.
• dbrgn 5y ago
  How is that related to serde?
• _xyub 5y ago
  I thought I'd share this project in case anyone wanted to quickly evaluate rust for web https://github.com/wulf/create-rust-app 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~
  • option_greek 5y ago
    Please consider giving warp as choice for the web server.
    • Wulf_ 5y ago
      Any particular reason?
      • option_greek 5y ago
        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).