This is similar to the issue https://github.com/springfox/springfox/issues/2263.

    @PostMapping(value = "/api/attachments/create", consumes = MULTIPART_FORM_DATA_VALUE)
    Response createAttachment(@RequestPart(value = "file") MultipartFile file);

I need to store an attachment received from one service to another service(My service is a mediator). So the problem is the attachment request received to my service with parameter name as linked but I need to send the request with name as file. Though I gave name/value as file it still uses the parameter name(linked) received from the request. I use spring feign client to make POST request. Whether the issue with feign or spring?

Comment From: Hemaraj-Gajaraj

Can anyone confirm is this a bug or something else?

Comment From: poutsma

I do not know anything about feign, but in Spring I would use the MultipartBodyBuilder for creating that request, and send it using the RestTemplate or WebClient. You can explicitly set the part name that way.

Closing because I don't think this is a Spring bug.

Comment From: Hemaraj-Gajaraj

@poutsma Then this document RequestPart is misleading it says we can set the name for requestpart annotation. And this issue occurs not only with feign but also in spring.

Comment From: poutsma

I've just created a new Spring Boot app with a the following handler method in a Spring Boot application:

    @PostMapping(value = "/api/attachments/create", consumes = MULTIPART_FORM_DATA_VALUE)
    ResponseEntity<String> foo(@RequestPart(value = "file") MultipartFile file) {
        return ResponseEntity.ok(file.getOriginalFilename());
    }

With the following command, this method is invoked correctly and returns file.txt:

curl -F 'file=@file.txt' http://localhost:8080/api/attachments/create

If I change the name of the request parameter from file to foo, the request is not resolved and I get and error:

curl -F 'foo=@file.txt' http://localhost:8080/api/attachments/create

So it looks like the name element of the @RequestPart annotation is treated like it should. The documentation does not look misleading to me.