You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Right now, a client can lock a server thread indefinitely by simply sending a Content-Length header larger than the data it is actually going to send.
Being able to set a timeout on reading a RequestBody may mitigate this. Unfortunately, this structure only implements the Read trait due to tiny-http also just returning a Read + Send value. There is no RawFd we could use for polling.
So how can such a timeout be implemented in Rouille?
Thanks in advance.
The text was updated successfully, but these errors were encountered:
This (timeouts on read/writes + timeouts/deadlines on whole request handling) and dynamically allocated thread-pool size is pretty much everything required to bring a gap between async and threaded http servers for most practical applications.
To what extent should the above (timeouts + deadlines) be the responsibility of the underlying HTTP server tiny-http and what parts should be handled by the web framework itself? tiny-http runs an 'acceptor' thread that just dispatches onto whatever it is provided, it would probably need to at least pass something up to handle timeouts / cancellations if it doesn't do it itself.
Hi!
Right now, a client can lock a server thread indefinitely by simply sending a
Content-Length
header larger than the data it is actually going to send.Being able to set a timeout on reading a
RequestBody
may mitigate this. Unfortunately, this structure only implements theRead
trait due totiny-http
also just returning aRead + Send
value. There is noRawFd
we could use for polling.So how can such a timeout be implemented in Rouille?
Thanks in advance.
The text was updated successfully, but these errors were encountered: