Menu
▾
▴
RE: [Springframework-developer] Multipart File Handling
|
From: Trevor C. <pr...@se...> - 2003-09-28 20:10:15
|
You will have complete control over how this is handled. With the =
default implementation (which is using commons fileupload) you can =
specify the maximum amount to store in memory, and the maximum to write =
to the file (which is the fallback method). Basically, by setting =
in-memory low (or to 0), you can avoid using it. With COS (which we =
will add support for later), there is no in-memory support currently. =
However configuration options for various "MultipartResolver"'s will =
obviously be different.
As far as a DOS/DDOS attack goes, I'm not sure how much this buys you =
though. But the configuration options will be there.
Trevor
-----Original Message-----
From: Colin Sampaleanu [mailto:col...@ex...]
Sent: September 28, 2003 3:49 PM
To: Trevor Cook
Cc: j=C3=BCrgen h=C3=B6ller [werk3AT]; al...@jt...; Spring Developers
Subject: Re: [Springframework-developer] Multipart File Handling
I'm sort of clued-out here (not knowing most of the context), but can=20
you guys clarify that this will still be able to handle file uploads=20
where the entier file doesn't have to reside entirely in memory? I=20
consider this critical for scalability and being able to handle DOS=20
attacks...
Regards,
Colin
Trevor Cook wrote:
>I think byte[] should work in most cases, and is simple enough to do. =
However, it does not provide certain features necessary if you are using =
"File" objects (such as size, etc.), and I don't think anyone want's the =
MultipartFile in their form beans.
>
>I have some ideas floating around on how to handle this, but they're =
still a little fuzzy. Some code/test cycles should figure them out. =
I'll be working on it this afternoon, so I'll send out more info once I =
have some concrete suggestions.
>
>Trevor
>
>
>-----Original Message-----
>From: j=C3=BCrgen h=C3=B6ller [werk3AT] =
[mailto:jue...@we...]
>Sent: September 28, 2003 10:20 AM
>To: al...@jt...; Trevor Cook; Spring Developers
>Subject: Re: [Springframework-developer] Multipart File Handling
>
>
>Alef,
>=20
>I'm not keen on introducing yet another converter interface, especially =
as there's hardly any variation possible in terms of file upload =
handling. I agree though that having MultipartFile in the object model =
isn't desirable.
>=20
>What about writing the automatic check in ServletRequestDataBinder so =
that it assumes a byte[] for the uploaded file? I can't think of any =
other generic type suitable for uploaded files. java.io.File is no =
candidate as we would need to determine a path to save the file to. I =
consider such persisting the responsibility of the application code =
itself, especially as the uploaded stuff will often be stored to a =
relational database.
>=20
>For anything else than byte[] as property type in a command object, =
even MultipartFile if desired, one can always override onBindAndValidate =
and perform manual binding. Would that be powerful enough for your use =
cases?
>=20
>Juergen
>=20
>=20
>
> -----Ursprngliche Nachricht-----=20
> Von: Alef Arendsen (JTeam) [mailto:al...@jt...]=20
> Gesendet: So 28.09.2003 15:31=20
> An: j rgen hller [werk3AT]; 'Trevor Cook'; 'Spring Developers'=20
> Cc:=20
> Betreff: RE: [Springframework-developer] Multipart File Handling
>=09
>=09
>
> In one of my previous mails I mentioned doing something like that. It =
involved base64 encoding the byte[] to a String, after which the =
propertyeditor picked it up, decoded it again into a byte[] and set it =
on the object! Arghhh.... (as in wow that's ugly ;-).
>=09
> I did this, because I rely completely on the mvc framework and 1) did =
not want to put in some MultiPart object in my object model, I just =
wanted a byte[] and 2) just didn't want to make compromises simply =
because of propertyeditors being only capable of handling Strings. Ok, =
the solution is nasty and definitely not up for adding, but I really =
think it should worked in such way that things stay consistent while on =
the other hand, not forcing a user at all to modify stuff in it's =
datamodel... May sound a bit harsh, sorry for that ;-)
>=09
> Would it be possible to define a simple Spring-proprietary conversion =
interface/class which users can implement themselves capable of =
transforming multpartfile object (or whatever other type) to objects =
defined in a user's datamodel. Something like the following.
>=09
> class FileUploadConvertor {
> public Object convert(MultiPartFile);
> }
>=09
> Just some thoughts...
>=09
> Alef
>=09
>=09
> -----Oorspronkelijk bericht-----
> Van: spr...@li... =
[mailto:spr...@li...] Namens j =
rgen hller [werk3AT]
> Verzonden: Sunday, September 28, 2003 2:31 PM
> Aan: al...@jt...; Trevor Cook; Spring Developers
> Onderwerp: Re: [Springframework-developer] Multipart File Handling
>=09
>=09
> Hi Alef,
>=09
> A PropertyEditor will always start with a String and convert it to =
some other type, in the web case applied to ServletRequest's =
getParameter values. Here we got MultipartFile instances, retrievable =
via MultipartServletRequest's getFile(String name) method: no Strings in =
the first place, thus the PropertyEditor mechanism is not applicable.
>=09
> We could possibly add a special check to ServletRequestDataBinder, =
binding MultipartFile instances to respective command bean fields of the =
same type in the case of a multipart request. That would work with any =
MultipartResolver implementation, as it could use the same API as manual =
file upload handling code that casts to MultipartServletRequest.
>=09
> Definitely a feature worth considering!
>=09
> Juergen
>=09
>=09
>=09
> -----Urspr ngliche Nachricht-----
> Von: Alef Arendsen (JTeam) [mailto:al...@jt...]
> Gesendet: So 28.09.2003 14:04
> An: jrgen h ller [werk3AT]; 'Trevor Cook'; 'Spring Developers'
> Cc:
> Betreff: RE: [Springframework-developer] Multipart File =
Handling
> =20
> =20
>=09
> Will there be a way - using this solution - to bind the file =
using a propertyeditor (or something else maybe), just as any other =
command object is filled with parameters from the request. For =
consistency, I think that's pretty important to be consistent.
> =20
> Furthermore I think it's pretty cool if the fileupload could =
be fixed before the 1.0 release! Good thing!
> =20
> Alef
> =20
> =20
> -----Oorspronkelijk bericht-----
> Van: spr...@li... =
[mailto:spr...@li...] Namens =
jrgen h ller [werk3AT]
> Verzonden: Sunday, September 28, 2003 12:33 PM
> Aan: Trevor Cook; Spring Developers
> Onderwerp: Re: [Springframework-developer] Multipart File =
Handling
> =20
> =20
> Hi Trevor,
> =20
> A MultipartResolver interface with implementations for Commons =
FileUpload and COS is fine with me - it just hadn't high priority since =
I proposed it half a year ago. As I still have a pretty clear picture of =
the issues, I'll be happy to review your code once you've checked it in. =
As this should be pretty straightforward, let's try to include this =
already in 1.0 M2 - at least with a Commons FileUpload implementation.
> =20
> BTW, in contrast to COS, Commons FileUpload doesn't provide a =
Servlet 2.3 filter anyway. This means that there would be some =
infrastructure code to write for that use case too, even when using =
standard filters. A simple but convenient Spring solution would =
definitely be a good thing.
> =20
> Juergen
> =20
> =20
> =20
> =20
> -----Ursprngliche Nachricht-----
> Von: Trevor Cook [mailto:pr...@se...]
> Gesendet: Sa 27.09.2003 19:35
> An: Spring Developers
> Cc:
> Betreff: [[W3-SPAM]] - [Springframework-developer] =
Multipart File Handling - Email found in subject
> =20
> =20
> =20
> First some history:
> =
http://sourceforge.net/mailarchive/message.php?msg_id=3D3891279
> =
http://sourceforge.net/mailarchive/message.php?msg_id=3D5175276
> =
http://sourceforge.net/mailarchive/forum.php?thread_id=3D3125561&forum_id=
=3D3028
> 7
> =
http://sourceforge.net/mailarchive/message.php?msg_id=3D6062288
> =20
> To address a few things Juergen mentioned previously.
> =20
> >> a less intrusive way would be to wrap the =
HttpServletRequest via a filter
> I personally don't like the filter approach, at least =
for the framework. It
> requires additional setup for the user (in the web.xml =
file) and might be
> less understandable since our normal strategy so far =
has been with resolvers
> inside the servlet.
> =20
> >>we would need to find concrete requirements for this
> We have numerous uses for file upload handling. We =
have a public photo
> contest where users can upload fotos. We have special =
access for suppliers
> to upload product files (csv) which we then add in to =
our ordering system.
> Finally, we have a web administration interface which =
allows our client to
> upload files to the website so they can be downloaded. =
I think that
> including this support (multipart handling) is a =
no-brainer.
> =20
> Basically, I have used COS exclusively in our =
projects, but I don't think
> that's easy for Spring to use (due to the licensing). =
I would simply code
> this according to Spring norms using an interface and =
a default version
> using Commons FileUpload. Later, if somebody wants to =
create a cos version
> we can (but to be honest, if we have a working, =
integrated solution I'm not
> sure that is necessary - at least not in the Spring =
framework). Basically,
> provide hooks and a default implementation, and allow =
users to adopt as
> necessary.
> =20
> In our project we had modified the AbstractController =
and put the code into
> it to handle the multipart processing, returning a =
wrapped
> HttpServletRequest through the handlers. This is very =
similiar to Juergen's
> outline =
(http://sourceforge.net/mailarchive/message.php?msg_id=3D3891279).
> =20
> Since we are migrating to the current Spring codebase, =
I need to move our
> multipart handling code. The main question is whether =
we keep it
> internally, or place it into Spring. I propose =
modifying
> org.springframework.web.servlet.DispatcherServlet to =
have a
> "MultipartResolver". In the DispatcherServlet, the =
resolver would be called
> to wrap the request in doService immediately before =
getHandler(request) -
> currently line 351, and then called to do any cleanup =
immediately before
> exiting the doService method.
> =20
> I have about 2/3 of the code already written, and I =
will be writing the rest
> between now and Monday. Does this strategy sound =
appropriate for Spring
> (meaning should I commit it to the Spring codebase) =
when it's finished?
> =20
> Trevor D. Cook
> Interprise Software
> =20
>
|
