On Thu, 29 Sep 2005 16:02:00 +0900, Zev Blut <rubyzbibd / ubit.com> wrote: > My colleagues and I have discovered a potential problem with the > implementation of the CGI library's read_multipart method. The > current CGI implementation will create a temporary file for many of > the multipart data entries if the posted content length is greater > than 10 kilobytes. > > I would like to ask what is the intended goal of the implementation? > Is the goal to make temporary files for each data entry that is more > than 10 kilobytes and keep entries that are less in StringIO objects? > > The reason I ask is that the current implementation works in a > different way. It will create temporary files for each data entry > until the remaining content data stream is less than 10 kilobytes. > Then it will use StringIO for the remaining entries. > > This implementation turns out to have disastrous consequences for some > of my applications. We have some situations where we send images and > many select options in a post. This ends up creating hundreds and > sometimes thousands of Tempfiles, which causes our servers to become > unresponsive. > > I have modified read_multipart to only create TempFiles for each data > entry greater than 10 kilobytes. With this modification our servers > are responsive and show no other problems with my change. > > I have made a few other changes to the implementation to use sub! > method calls to hopefully remove unneeded duplication of large buffers. > I dug through the CVS history and it appears it was originally using > such a sub! call, but later when to "buf = buf.sub" calls, is there a > reason why? If so I will revert back to "buf = buf.sub". > > Ignoring a few minor style changes in my implementation and or my > implementation all together, the main point of discussion I would like > to start is if the current 10 kilobyte implementation is correct of if > the intended goal of my modification is correct? If my modification > is not too offensive I can integrate it with cgi.rb and post a patch. Am I not being clear or is everyone too busy? :-) Cheers, Zev