There are patches in the queue that bring a basic level of flexibility and security (of a sort) to multipart file upload behavior.
Here are a few follow up issues from the initial discussion. Some are remaining action points, some are just updates: 1) There is the idea that choosing behaviour per-pipeline would be the best. Looking into this some more, I'm not sure it's feasible to do so. The parameters in the request are handled by the servlet before Cocoon even enters the picture. Does anyone have a suggestion for how to accomplish this? I'm not sure it's needed. I think this same issue makes it impractical to move these configurations into cocoon.xconf, which I had hoped to do. Some of the suggestions below make me more comfortable with this though. 2) There was a suggestion to make the uploaded file saved to disk temporary - that is have the FilePartFile removed at the end of the request. I think this is a good idea if it's a configurable option via web.xml. What do others think? 3) The FileUploadAction is a good idea (IMHO, and it exists but not in CVS). This would enable users to choose an authenticated pipeline to deal with file uploads, specifying via sitemap parameters where to store the file, what to name it, and a maximum accepted file size. A similar action could store the file as a BLOB if desired. The name of this action is deceiving since the file will already be on disk (temporarily if the second point above is followed) or in memory. 4) Multiple file uploads though mentioned in the RFC, don't seem to be supported in browsers. Am I wrong? Constructing an HTTP request by hand using the proposed structure results in no file upload and no error logged, the same as other malformed requests that I tried. In any case, the current functionality works fine with multiple file fields: <input type="file" name="file1"> <input type="file" name="file2"> I'm happy with this behavior. 5) The maximum file size default in web.xml works for "honest" requests, but I only did cursory tests for requests constructed to deceive. The logic in MultipartParser relies on request.getContentLength(). There may be logic elsewhere to ensure that getContentLength is accurate. Can someone check that? 6) In my patch, I didn't make SimpleRequestFactoryImpl the default in web.xml as I originally intended because it would break the sample by default, and I no longer saw it as a big security issue. Anyone still interested in all this? Geoff __________________________________________________ Do you Yahoo!? Faith Hill - Exclusive Performances, Videos & More http://faith.yahoo.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
