cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Antonio Gallardo Rivera <agalla...@agsoftware.dnsalias.com>
Subject Re: [VOLUNTEER] Re: DO NOT REPLY [Bug 13541] New: - SAVE_UPLOAD_FILES_TO_DISK should be configurable
Date Mon, 14 Oct 2002 17:45:58 GMT
El Lunes, 14 de Octubre de 2002 11:39, Geoff Howard escribió:
> > 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?

Can be this size a config parameter?

Antonio Gallardo.
>
> > 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: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org

---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message