Affects: \5.3.8+

When submitting a multipart request that has a part that does not specify a filename in the Content-Disposition, then the part is ignored and a validation error is shown that the "Required request part '...; was not present'.

The problem appears to be in StandardMultipartHttpServletRequest.parseRequest() (L:102) where it fails to add the MultipartFile to the MultiValueMap if the filename is null.

I am trying to submit a multipart form that has two parts. One with a JSON part named 'data' and another part named 'file' that is either a binary file (with the appropriate mime type for the file) or data with a mime-type of 'text/uri-list' which is a newline delimited list of URLs to fetch.

When submitting the part as say a PDF file with the Content-Disposition filename attribute set and mime-type of 'application/pdf' and the request works. When you remove it because it's not-applicable to a part of mime-type 'text/uri-list', then the request fails with "Request request part 'file' is not present".

My understanding is that the filename attribute on the Content-Disposition is optional. The comments on MultipartFile.getOriginalFilename() also correctly call out the function can return null if it has not been provided by the client.

Comment From: poutsma

Parts in a multipart request that do not have the filename in their Content-Disposition header are not considered file uploads, and therefore cannot be bound to MultipartFile objects. They can however, be bound to other types instead, by using the @RequestPart annotation. JSON can be deserialized into objects, for instance, as explained in the reference documentation.

Comment From: h4xmd

This is a bit odd, the filename is not mandatory in the request. The MultipartFile class even says this field may be null so your response is out of line with the intention of the class.

Comment From: Laurens-W

@poutsma As @h4xmd has pointed out, as well as according to this RFC section https://www.rfc-editor.org/rfc/rfc7578.html#section-4.2 a part might not contain a filename even though its content might be a file. However from the platforms perspective it makes sense to assume anything that does not provide a file name is not a file as you have no reliable way of determining whether it actually is.

In my case I have control over both client and server side. They are both generated based on an openapi spec, where a combination of type:string and format: binary results in the parameter being generated as a File. In the clients case represented as a Resource and the servers case as MultiPartFile.

Would it be good practice to prevent the client from sending a file without a name or should the server side handle this as part of request validation?

Comment From: h4xmd

It shouldn't care to Spring if the data inside of a Form part is a 'file' or not? The filename is just metadata for the multipart data.

What if the client POST'd the data from a stream and not from a file? You could set some random characters as the filename to make Spring happy but it's a bit clumsy.

Comment From: Laurens-W

In my case after looking at it again it's been decided to have the server side use javax.servlet.http.Part which still provides all the context we need :)