There's a problem with the way we currently handle sending a file in the
nsFormFrame::ProcessAsMultipart code. In short, if we can't determine
the size of the file "up front", then we can't send a correct
Content-Length header (see bug 62582 for details). I'd like to fix this
code but would like to air my ideas first, before committing them to
code. Your feedback is most welcome.

There are several other problems with the current code in addition to
the fundamental problem stated above. First, everything is done twice;
we make two passes through the form controls, the first to compute the
Content-Length and the second to actually write the content to a file.
This is inefficient, bloats the code, and makes any future code changes
error prone. Second, if a file is modified while this code is running
then it is possible (in fact likely) that we will send an incorrect
Content-Length header. Third, the error handling is virtually
nonexistent (errors are detected but we don't respond correctly to
them).

I propose fixing all of these problems. Instead of making two passes
through the form controls we'll just make one, and write out all the
HTML to a temporary file. This means that we don't need to rely upon
stat to get any input file size, and neither do we have a window between
getting the file size and actually reading the file where the contents
(and therefore size) could change. At the end of the first (and only)
pass we'll then know the correct Content-Length and so we can output the
Content-Length header and copy the contents of the temporary file.

The down side to this approach is that we have the overhead of writing
and then reading an extra temporary file. But the benefits are that we
only make one pass through the form controls (which should make future
maintenance easier), we'll always get any file sizes correct, and the
resultant code should be smaller. I also hope to fix the error handling.
I think the benefits outweigh the drawbacks.

Thoughts? Comments?


Reply via email to