It seems that StandardServletMultipartResolver wraps multipart/mixed requests with StandardMultipartHttpServletRequest which fails in Jetty due to strict conformance to the spec.
I.e. HttpServletRequest.getParts() should only be called when the content type is multipart/from-data and not just any content type that starts with multipart/
Spring Framework Version: 5.2.9
Please see https://github.com/eclipse/jetty.project/issues/6196 for details. (exception and original request)
Comment From: jhoeller
How do you intend to handle you multipart/mixed requests, actually? It looks like you'd prefer Spring's multipart resolution to ignore them but then you might go on to process them in a custom way?
Comment From: jhoeller
It seems generally sensible to delegate to the container to find out about actual multipart support. If Tomcat accepts other multipart content types as well, we should arguably let it happen that way. The problem seems rather that we're eagerly calling HttpServletRequest.getParts() in the initial request processing phase; if we only triggered this in case of actual MultipartRequest API interaction from the application's side, we wouldn't expose the application to it unnecessarily.
You can get such lenient handling already by defining your own StandardServletMultipartResolver bean and setting the resolveLazily property to true. Maybe we need to make this more obvious or even reconsider the default there.
That said, it would help a lot to understand your specific scenario. I wonder what's commonly expected for such non-form multipart request types: rejecting them upfront if not supported, or rather letting the application deal with it in a custom way?
Comment From: jhoeller
I've introduced a strictServletCompliance flag on StandardServletMultipartResolver, narrowing the applicability of Spring's MultipartHttpServletRequest to form data only. Multipart request with content types other than "multipart/form-data" then enter the application without Spring's request wrapper, leaving it up to the application to process it (or to reject it in a custom way).