Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Configurable Slowloris size #418
I know there's been a lot of history around the Slowloris protection here and in the mailing list. This change simply seeks to make the hard-coded value configurable by settings, with a continued default value of 2048 bytes.
The current documentation indicates that
which suggests that after 2048 bytes of the request body have been processed, through however many reads, the timeout will be tickled. But the current implementation seems to tickle the timeout only after a single read consumed at least 2048 bytes. Sending in at least 2048 bytes across multiple writes without any single write at least 2048 bytes will trigger the Slowloris protection. A stateful counter of bytes here that resets on tickle might be useful.
Our current warp use-case is an IoT application that POST's low volume telemetry data over long-lived streaming requests. Our devices end up looking a lot like a Slowloris attack :) While in the long run HTTP/2 might be a better fit and its timeout tickling better-suited, we'd still like to be able to use HTTP/1 as well, and configure down the Slowloris prevention value without having to increase the timeout value and lose client responsiveness detection.
I couldn't piece together in
And thanks for the great software! We love running on top of warp!