It would be convenient if Spring controller can handle a multipart file request where filename is empty.

Controller:

@PostMapping(path = "/upload", consumes = MediaType.MULTIPART_FORM_DATA_VALUE)
@ResponseStatus(code = HttpStatus.CREATED)
public String upload1(@RequestPart("file") MultipartFile file, @RequestPart("payload") Map<String, Object> message) {
    // ...
}

Client (using RestEasy 2.3.10 multipart which doesn't support passing filename):

ApacheHttpClient4Executor executor = new ApacheHttpClient4Executor();
final String url = "http://localhost:8080/upload";
ClientRequest clientRequest = executor.createRequest(url);

MultipartFormDataOutput multipartBody = new MultipartFormDataOutput();
multipartBody.addFormData("file", getFileBytes(), MediaType.APPLICATION_OCTET_STREAM_TYPE); // no extra parameter for filename in this version
multipartBody.addFormData("message", "{\"item-name\": \"my-cool-file\"}", MediaType.APPLICATION_JSON_TYPE);
clientRequest.body(MediaType.MULTIPART_FORM_DATA_TYPE, multipartBody);

ClientResponse<?> response = clientRequest.post();

The passed multipart body:

--bf99dc24-6170-4ddc-9ab5-52d0d13bfa12
Content-Disposition: form-data; name="file"
Content-Length: 29
Content-Type: application/octet-stream

name;city
"John Doe";"London"
--bf99dc24-6170-4ddc-9ab5-52d0d13bfa12
Content-Disposition: form-data; name="message"
Content-Type: application/json

{"item-name": "my-cool-file"}
--bf99dc24-6170-4ddc-9ab5-52d0d13bfa12--

The above leads to following error in the Spring Controller:

WARN 24800 --- [nio-8080-exec-4] .w.s.m.s.DefaultHandlerExceptionResolver : Resolved [org.springframework.web.multipart.support.MissingServletRequestPartException: Required request part 'file' is not present]

All works fine when there is a filename in the multipart payload:

--gG95MiIJuOydnJq_teLCCqII-IV0l8pZQxzUa
Content-Disposition: form-data; name="file"; filename="demo.csv"

However in case of environment specifics - it's challgenging to update version of the rest mime support. It might be convinient to be able to process requests without filename (as soon as part name is provided as in the given examples above).

Comment From: rstoyanchev

This can lead to inconsistencies, e.g. you would get it with MultipartFile but not with collection or array of MultipartFile, and one can make the opposite argument that it should be rejected.

Why does it matter to have it injected as MultipartFile if it doesn't even have a filename? You could also inject it as InputStream or any other type supported by a registered HttpMessageConverter.

Comment From: javornikolov

This can lead to inconsistencies, e.g. you would get it with MultipartFile but not with collection or array of MultipartFile, and one can make the opposite argument that it should be rejected.

I am not familiar with the details but I am not sure this is introducing new inconsistencies - there is already a name header in the individual parts which may be used. Besides - I am not sure there is anyway kind of validation of duplicated filename. If filename is important - it could be verified explicitly. It's a subject of the specifics of the particular details of the service. Whatever inconsistencies may be resolved via filename, I think they may be similarly resolved via name header.

There is RFC https://www.ietf.org/rfc/rfc2388.txt suggesting that filename MAY be provided (but it doesn't say it's mandatory).

Why does it matter to have it injected as MultipartFile if it doesn't even have a filename? You could also inject it as InputStream or any other type supported by a registered HttpMessageConverter.

The scenario is that we have both binary data and structured data (metadata, in json format in this case). MultpartFile was just something which popped up as typical approach for handling such cases.

We haven't used InputStream or HttpMessageConverter arguments in controllers yet in our project. It seems a valuable insight, thank you about it!

Comment From: rstoyanchev

No problem, injecting InputStream should do it.