Configurable Slowloris size

[mfine]

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

Every time at least 2048 bytes of the request body are read, the timeout is tickled.

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 RunSpec.hs how the Slowloris prevention was being validated, but would be happy to add a test that checks that the new Slowloris size is honored with a little guidance.

And thanks for the great software! We love running on top of warp!

[erikd]

👍

[snoyberg]

This looks great, thanks!

[mfine]

Thanks so much for the quick turn around!

[kazu-yamamoto]

👍