DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=18492>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=18492 Problem with upload of files. ------- Additional Comments From [EMAIL PROTECTED] 2003-04-08 11:39 ------- The problem is that mod_cgi[d] doesn't start reading output from the script until it has transferred the entire request body to the script. So scripts that generate more than 4K* of output before reading all the request body will block while writing the response body since mod_cgi[d] isn't reading, and mod_cgi[d] will block writing the request body since the script isn't reading. *replace 4K with whatever the kernel buffer size is for pipes (mod_cgi) or Unix sockets (mod_cgid) I was able to reproduce this and put together a test patch yesterday. Unfortunately, the way the patch worked was to save all intermediate output in a brigade prior to the point where we had written all of the request body to the script, so we can pass that brigade (with the pipe bucket behind it) to ap_scan_script_header_err_brigade(). But that brigade could hold arbitrary amounts of data (memory use unbounded), so this doesn't seem to be a good solution. Some changes would be needed to the way we scan for header lines in the script output so that it can be accomplished even before we finish writing the request body to the script. I'll attach the clumsy patch I was playing with in case anybody is interested. I don't think it should be used as-is unless perhaps in an environment where it is known that the script output won't be unbounded up until the point that the request body has been written to the script. On the somewhat-bright side, it looks like this was broken in Apache 1.3 too, so there is some indication that this problem wasn't a showstopper for everyone. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
