cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Geoff Howard <cocoonge...@yahoo.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:39:09 GMT
> 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: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message