You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Our support for Servlet 3.0 Part lists and arrays is unfortunately highly inconsistent with the MultipartFile handling that it was supposed to align with. Our MultipartRequest interface allows for access to multiple files which got uploaded under the same name; this is also what a declared MultipartFile list/array argument would receive. However, the Servlet 3.0 HttpServletRequest.getParts method does not retrieve parts by name but rather always returns all parts of the given request, so we accidentally called that method without any use of our specified part name... Let's make this consistent for 4.3.
As of 4.3, Part list and array resolution takes the specified name into account, either from the annotation value or from the method parameter name.
If some application code accidentally relied on Part list/array resolution despite a name mismatch, it needs to be fixed to match the actual part name.
Juergen Hoeller opened SPR-13893 and commented
Our support for Servlet 3.0
Part
lists and arrays is unfortunately highly inconsistent with theMultipartFile
handling that it was supposed to align with. OurMultipartRequest
interface allows for access to multiple files which got uploaded under the same name; this is also what a declaredMultipartFile
list/array argument would receive. However, the Servlet 3.0HttpServletRequest.getParts
method does not retrieve parts by name but rather always returns all parts of the given request, so we accidentally called that method without any use of our specified part name... Let's make this consistent for 4.3.Affects: 4.2.4
Issue Links:
@RequestPart
(...) MultipartFile[] does not work (List<MultipartFile works)Referenced from: commits b4f33ad
The text was updated successfully, but these errors were encountered: