> That is exactly what is done in > CocoonServlet.service: > > HttpServletRequest request = > RequestFactory.getRequestFactory(requestFactoryClass).getServletRequest( > req, > > CocoonServlet.SAVE_UPLOADED_FILES_TO_DISK, > > this.uploadDir, > > CocoonServlet.ALLOW_OVERWRITE, > > CocoonServlet.SILENTLY_RENAME, > > this.maxUploadSize);
I've been working on this and discussing it off list with Leo, who is pursuing orthogonal changes to the scope of the RequestFactory as he mentioned. For starters, I am preparing a patch that makes all the above listed hardcoded values configurable in web.xml. The work is trivial and is a start in the right direction. > 3.) Refactor MultipartRequestFactoryImpl and > friends. This is probably beyond my ability to commit to right now, at least by myself. Are you volunteering to help with this? > This could actually be turned into an > FileUploadAction with > configuration > parameters: > > <map:act type="upload" src="path/to/inbox"> > <map:parameter name="overwrite" > value="deny|allow|rename"/> > <map:parameter name="maxsize" value="10000000"/> > ... Thank you for your file > </map:act> > ... Sorry, your file could not be stored There is a similar action in the archives written by Jeroen ter Voorde. I think it should be included in cvs was planning on asking him to submit it, or allow me to do so. I'll look into the congiguration suggestions above. The problem is that without further "architecture", the file handling code needed for this kind of action is in part duplicated from MultipartRequestFactoryImpl. So here's a discussion topic: where should common code for handling multipart parsing go if it is to be available to the request components listed above as well as to actions and in the future Modules? > SimpleRequestFactoryImpl should become the fallback > request factory in > CocoonServlet, unless web.xml (or cocoon.xconf) says > otherwise. I agree - I'll include this change in my patch. > The request factory in the example configuration > should be > MultipartRequestFactoryImpl with a reasonable limits > for array/file > sizes. The current configuration (at least 2.1dev) is MultipartRequestFactoryImpl, and the default max upload is 10M. Is that a reasonable size? > 1.) <input type=file> allows also for multiple file > selection. That is > not yet handled at all. I'll look at this. > > 2.) Even if file uploading is disabled, read out the > request body to > advance to the > next HTTP/1.1 request in the socket. (When using an > upstream load > balancer, the > following request may even be from a different > user.) Disabled, meaning you are using SimpleRequestFactoryImpl? Is there someone willing to look at this? > > 3.) Sort out the character encoding between the file > content sent by the > browser > and what the servlet expects. Any volunteers? > > So there is plenty of volunteer work left to be > done... > > Cheers, Alfred. Yup, 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]
