--- Comment #6 from ---
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

It seems then, the story is more complicated than that. I'll take your word for

> 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?

> 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.

You are receiving this mail because:
You are the assignee for the bug.
To unsubscribe, e-mail:
For additional commands, e-mail:

Reply via email to