<snip/>By the way, I think there are bigger security problems in cocoon...
Also, is cocoon-reload still enabled by default? seems a wget in a loop with ?cocoon-reload=true could put a site in a world of hurt... (by the way, last time I checked Jetty/Cocoon cvs is barfing on that..)
With jetty, try http://localhost:8888?cocoon-reload=true - without '/' symbol. Jetty is ... different ... from other engines.
I've worked on the multipart file uploads because I felt the original status posed security/abuse issues. It's now at a better point but I think there are still some issues I'm not (at an RF level) convinced are OK. IIRC the default is now to allow "in-memory" uploads only which is a step better.
Is it? With in-memory upload you can get to OutOfMemory exceptions and potentially corrupt cocoon instance. With file uploads, you can create 100Mb file systems which you can fill up but you won't disturb functionality of the server. I don't see how in-memory uploads are more secure; I see them as *less* secure.
And, of course, best approach is no uploads at all :)
<snip/>
One I'd really like to look into is places where directory traversal could be successful, depending on your matchers.
That's might be real security issue.
Vadim
