I have been able to confirm this bug but have not designed a test case. It should be fairly easy to duplicate, however. My particular test case was using phpicalendar 2.31 with publish.php on Sunbird calendars. Previously, this worked fine, but upon using fcgid 2.3.4, I started getting calendar corruption (the publish is done by reading the php://input stream).
I was able to verify that the corruption occurred at right around the 64K mark of the uploaded data. Basically it appeared that a chunk of data was dropped at that point, but more data was written afterward. Upon realizing this, I began to research any information having to do with 64K. I learned that there is a 64K "limitation" by default in fcgid, via: FCGIDMaxRequestInMem The default value of this variable is 64K. Upon changing this to a larger value (I used 2^21, since that matches the php upload limit default), the corruption disappeared. Obviously, since the value of the variable only is supposed to change WHERE the data is buffered, and not WHAT is buffered, there must be some sort of bug, here. As soon as there is a requirement to cache on disk, the data is not correctly fed to the input stream. Something is lost. I'm not sure the best way to make an easily reproducible test case, since my configuration requires php. Perhaps a perl cgi to read the input, and a simple web request html file to post it... -Dan
