https://bz.apache.org/bugzilla/show_bug.cgi?id=67626
--- Comment #5 from Michael Osipov <micha...@apache.org> --- (In reply to hans.risser from comment #4) > Hi Michael, thanks for the additional context - I just wanted to make sure I > follow completely. > > > The bundled Commons Upload MUST NOT be used to parse anything but, as Mark > > said, > > form data as per Servlet spec. Use an external Commons FileUpload. > > Do you mean to say that > 1) you disagree with Mark that Tomcat _maybe_ could go beyond the spec if it > permits or > 2) that the spec doesn't permit it? I would not implement anything beyond the spec because: 1) this opens a door to inconsistency and even more bugs/issues 2) form-data has been designed for the browser only, it has no other reasonable purpose, IMHO 3) Keep Tomcat code as simple as possible > --- > > I'm also not positive I understand your proposal to > > > Use an external Commons FileUpload > > Do you mean to say we should opt to receive a bare HttpRequest and put it > through Commons FileUpload ourselves instead of through the Framework, and > then make use of some kind of configuration or extension options? Yes, YOU must do it. The support from Spring Boot is rather limited, designed for the browser only, nothing else. I don't even understand why they match "multipart/*". But again, what options? Five of them which are obvious... > --- > > As for your comments of Spring Boot - I believe it would, from that piece of > documentation, allow us to integrate our own Multipart resolver and handle > all of this ourselves, but as an application developer, that doesn't seem to > be a very enticing prospect. Why not? We haven't tried to integrate into the resolver because it too specific for form-data. You may raise an issue with Spring Boot to generalize it. We have a quite extensive multipart/related usecase quite similar to SOAP's MTOM/XOP. > --- > > Since we are in a situation to do that, we have chosen to take a pragmatic > approach and use multipart/form-data, even though I would have preferred > multipart/mixed from the semantic descriptions, so if you believe there's no > further interest in this, feel free to close. This is just wrong. You seem to have just a hammer and see nails only. > It was surprising to me that other multipart types aren't in the scope of > Tomcat here, but if that's the situation I thank you for taking the time to > enlighten me at the very least =) Why? multipart is complex, regardless how good you try to do you will never be able to provide a generic and good solution to it. Do you know now long the contractor needed to understand to follow Content-ID pointers? Commons FileUpload and/or mime4j from Apache James work perfectly for us even for gigabyte size parts. -- You are receiving this mail because: You are the assignee for the bug. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
