Menu
▾
▴
Re: [Springframework-developer] Multipart File Handling
|
From: Colin S. <col...@ex...> - 2003-09-28 19:50:09
|
I'm sort of clued-out here (not knowing most of the context), but can
you guys clarify that this will still be able to handle file uploads
where the entier file doesn't have to reside entirely in memory? I
consider this critical for scalability and being able to handle DOS
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ürgen höller [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,
>
>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.
>
>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.
>
>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?
>
>Juergen
>
>
>
> -----Ursprngliche Nachricht-----
> Von: Alef Arendsen (JTeam) [mailto:al...@jt...]
> Gesendet: So 28.09.2003 15:31
> An: j rgen hller [werk3AT]; 'Trevor Cook'; 'Spring Developers'
> Cc:
> Betreff: RE: [Springframework-developer] Multipart File Handling
>
>
>
> 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 ;-).
>
> 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 ;-)
>
> 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.
>
> class FileUploadConvertor {
> public Object convert(MultiPartFile);
> }
>
> Just some thoughts...
>
> Alef
>
>
> -----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
>
>
> Hi Alef,
>
> 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.
>
> 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.
>
> Definitely a feature worth considering!
>
> Juergen
>
>
>
> -----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
>
>
>
> 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.
>
> Furthermore I think it's pretty cool if the fileupload could be fixed before the 1.0 release! Good thing!
>
> Alef
>
>
> -----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
>
>
> Hi Trevor,
>
> 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.
>
> 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.
>
> Juergen
>
>
>
>
> -----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
>
>
>
> First some history:
> http://sourceforge.net/mailarchive/message.php?msg_id=3891279
> http://sourceforge.net/mailarchive/message.php?msg_id=5175276
> http://sourceforge.net/mailarchive/forum.php?thread_id=3125561&forum_id=3028
> 7
> http://sourceforge.net/mailarchive/message.php?msg_id=6062288
>
> To address a few things Juergen mentioned previously.
>
> >> 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.
>
> >>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.
>
> 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.
>
> 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=3891279).
>
> 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.
>
> 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?
>
> Trevor D. Cook
> Interprise Software
>
>
|
