>-----Original Message-----
>From: Geoff Howard [mailto:[EMAIL PROTECTED]]
>Sent: Mittwoch, 16. Oktober 2002 18:27
>To: [EMAIL PROTECTED]
>Subject: file upload follow up
>
>
>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.
Making it per-pipeline is not possible because the
pipeline selection should to be able to assume that
all request parameters are available.
The HttpServletRequest coming from the servlet engine
has already decoded the URL and parameters from the
query string parameters. That is enough information
to search cocoon.xconf for a suitable request factory.
For example, in a virtual hosting setup one could then
configure different max-upload-size depending on the
port number or URL prefix.
Sure it is not nice to put stuff into cocoon.xconf which
conceptually belongs into the sitemap. Maybe we should
have a mechanism to override cocoon.xconf defaults with
vhost specific configurations.
>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?
Why should it be configurable to shoot yourself into the
foot? If the framework is not cleaning up, who will
before your disk becomes full?
Get away from the idea that upload requests are just a
replacement for ftp PUT. Rather think of them as a
convenient way for the user to cut&paste the content of
a file into a textarea.
If the application wants to store the data as permanent
file, it can do so easily with full control where and what
format.
We should have some SoC here. It only costs one additional
file copy operation for the special use case of a public
upload directory.
>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.
FileUploadAction is mainly just the replacement for the
functionality lost by using tempory files in FilePartFile.
>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.
Me too.
>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?
The client has to tell in the Content-Length header,
how many bytes follow in the request body. If the client
lies or the server does not read out the socket properly,
the requests following in the HTTP/1.1 will not be recognizable.
That is no bother if the requests come all from the same user.
But what if an upstream proxy channels requests from different
users through the same connection? (I don't know if mod_proxy
or mod_jk do 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
Sure, I hope your fixes make it into 2.1 or even 2.0.x.
Cheers, Alfred.
This message is for the named person's use only. It may contain
confidential, proprietary or legally privileged information. No
confidentiality or privilege is waived or lost by any mistransmission.
If you receive this message in error, please notify the sender urgently
and then immediately delete the message and any copies of it from your
system. Please also immediately destroy any hardcopies of the message.
You must not, directly or indirectly, use, disclose, distribute, print,
or copy any part of this message if you are not the intended recipient.
The sender's company reserves the right to monitor all e-mail
communications through their networks. Any views expressed in this
message are those of the individual sender, except where the message
states otherwise and the sender is authorised to state them to be the
views of the sender's company.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
