https://bz.apache.org/bugzilla/show_bug.cgi?id=67626
--- Comment #7 from Michael Osipov <micha...@apache.org> --- (In reply to hans.risser from comment #6) > Gotcha - it would have been handy for our use case, but I can see why you'd > want to keep to spec, of course. > > Considering some parts here: > > > this opens a door to inconsistency and even more bugs/issues > > > 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 > > makes me suspect there might be more differences between form-data and > multipart than I have understood yet. > They seemed, at the surface level, very similar in handling, perhaps also > because it was possible to somewhat make them work by accident with the > current code. > > It seems then, the story is more complicated than that. I'll take your word > for it. > > > I don't even understand why they match "multipart/*". > > I can see how keeping this open might make sense for Spring in case any of > the servlet containers _want_ to support more than form-data per default? Maybe, but then they need to document and enable only on those which do support. It does help when the stuff is known to fail and people don't understand the issue. > > But again, what options? Five of them which are obvious... > > > Yes, YOU must do it. > > > Commons FileUpload and/or mime4j from Apache James work perfectly for us > > even for gigabyte size parts. > > Thanks for the pointers. If I get to make a deeper dive on this, that will > be very useful. > > > This is just wrong. You seem to have just a hammer and see nails only. > > Somewhat true, perhaps, and what time constraints can do to us. The sonner you address this, the cheaper it will be... @Mark, do you want to add something or should I close this one? -- 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
