file upload follow up

[Geoff Howard <co...@yahoo.com>]

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