It is trivial to DoS starman: Send a chunked request that has no end. This will fill /tmp (or $ENV{TEMPDIR}) and prevent all other chunked requests from working (based on reading the code). Worse, based on other bug reports, the server process will just continue to try to use even more disk space, ignoring the failures and keeping the disc full until the client decides to end the request.
So, yes, Plack::TempBuffer needs to die() when adding to a temp file fails (as asked in other bugs). And, yes, a failure writing a response or reading more of a request needs to fail, not hang (see other bugs).
But there also needs to be support for a maximum request size. For many instances, this will be a simple fix.
I don't know if you want to try to do something fancy for when a maximum request size hasn't been set. For example, you could look at free space in $ENV{TEMPDIR} at start-up or periodically and enforce a max request size as some fraction of that value.
It is trivial to DoS starman: Send a chunked request that has no end. This will fill /tmp (or $ENV{TEMPDIR}) and prevent all other chunked requests from working (based on reading the code). Worse, based on other bug reports, the server process will just continue to try to use even more disk space, ignoring the failures and keeping the disc full until the client decides to end the request.
So, yes, Plack::TempBuffer needs to die() when adding to a temp file fails (as asked in other bugs). And, yes, a failure writing a response or reading more of a request needs to fail, not hang (see other bugs).
But there also needs to be support for a maximum request size. For many instances, this will be a simple fix.
I don't know if you want to try to do something fancy for when a maximum request size hasn't been set. For example, you could look at free space in $ENV{TEMPDIR} at start-up or periodically and enforce a max request size as some fraction of that value.