The discussion about filters got me thinking about places where we could use multiplexed I/O in Apache 2.0's filter, which led me to mod_cgi/cgid. In my research I think I may have found a long-standing possible deadlock (and denial of service) in how we pass input bodies to CGI scripts. I was able to reproduce both failure cases on Apache 1.3.25-dev and I suspect the same problem still exists today:
1) If the script doesn't consume the input data, and the data exceeds the buffer sizes of the operating system, then the httpd process and the CGI child will deadlock. (Note: The CGI spec specifically states that scripts are not obliged to read the data. See sect. 6.2 here: http://cgi-spec.golux.com/draft-coar-cgi-v11-03-clean.html#6.0) 2) If the script writes enough data to fill its output buffers without consuming enough of the input data such that the entire input body is contained in the operating system's buffers, then a deadlock will also occur in the same way as above. The simple workaround is to add a LimitRequestBody directive to your httpd.conf that is smaller than the I/O buffers on your system. I'm not as familiar with the Apache 1.3 code as I'd like, but I suspect that we should be pulling the descriptors out of the buff_struct available to mod_cgi, and using those in a poll set to perform multiplexed I/O. A solution in 2.0, however, is not as straightforward. In the long term I'd like to start profiling cases where multiplexed I/O is either necessary or beneficial. Then I think we can start talking about how to design this in, either at the filter-stack level, the ap_get_brigade()-level, or somewhere else. -aaron
