resttemplate multipart post with InputStreamResource not working [SPR-13571]

Marcus Schulte commented

Actually ResourceHttpMessageConverter seems a bit broken to me, when it checks whether it should ask a resource for its content-length by comparing its type to a constant:

@Override
protected Long getContentLength(Resource resource, MediaType contentType) throws IOException {
     // Don't try to determine contentLength on InputStreamResource - cannot be read afterwards...
     // Note: custom InputStreamResource subclasses could provide a pre-calculated content length!
     return (InputStreamResource.class == resource.getClass() ? null : resource.contentLength());
}

This gives anyone inheriting from InputStreamResource a hard time conforming to the Liskov principle.

For me, a combination of a custom-named resource and a slightly altered version of ResourceHttpMessageConverter does the trick:

/**
 * This class leaves it to the resource-implementation to decide whether it can reasonably supply a
 * content-length. It does so by assuming that returning {@code null} or a negative number indicates
 * its unwillingness to provide a content-length.
 *
 */

public class ResourceHttpMessageConverterHandlingInputStreams extends ResourceHttpMessageConverter {

    @Override
    protected Long getContentLength(Resource resource, MediaType contentType) throws IOException {
        Long contentLength = super.getContentLength(resource, contentType);

        return contentLength == null || contentLength < 0 ? null : contentLength;
    }
}

Then, a resource like the following works

 /**
     * Works with {@link ResourceHttpMessageConverterHandlingInputStreams} to forward input stream from
     * file-uploads without reading everything into memory.
     *
     */
    private class MultipartInputStreamFileResource extends InputStreamResource {

        private final String filename;

        public MultipartInputStreamFileResource(InputStream inputStream, String filename) {
            super(inputStream);
            this.filename = filename;
        }
        @Override
        public String getFilename() {
            return this.filename;
        }

        @Override
        public long contentLength() throws IOException {
            return -1; // we do not want to generally read the whole stream into memory ...
        }
    }

Of course, the broken Converter needs to be replaced in the RestTemplate:

List<HttpMessageConverter<?>> messageConverters = this.restTemplate.getMessageConverters();
       for (int i = 0; i < messageConverters.size(); i++) {
           HttpMessageConverter<?> messageConverter = messageConverters.get(i);
           if ( messageConverter.getClass().equals(ResourceHttpMessageConverter.class) )
               messageConverters.set(i, new ResourceHttpMessageConverterHandlingInputStreams());
       }

A method like Resource.isContentLengthAvailable() along with corresponding code to support it would be nice to have …

Brian Clozel commented

In order to properly write the multipart request, the FormHttpMessageConverter configured automatically with the RestTemplate will write all parts; if a part inherits from Resource, it calls the Resource.getFilename() method to get a file name, see the getFilename() method. If no file name is found, then this part is written as a “regular” part, not a file, in the content-disposition part of the message.

In your case, you could do the following:

@RequestMapping(method = RequestMethod.POST)
public void uploadFile(@RequestParam("customerId") int customerId, @RequestPart("file") MultipartFile multipartFile) {
  MultiValueMap<String,Object> parts = new LinkedMultiValueMap<>();
  parts.add("customerId", customerId);
  try {
    parts.add("file", new MultipartFileResource(multipartFile.getInputStream()));
  } catch (IOException e) {
    throw new RuntimeException(e);
  }
  HttpHeaders headers = new HttpHeaders();
  headers.setContentType(MediaType.MULTIPART_FORM_DATA);
  HttpEntity<MultiValueMap<String,Object>> request = new HttpEntity<>(parts, headers);
  restTemplate.exchange("http://localhost:8080", HttpMethod.POST, request, Void.class);
}

private class MultipartFileResource extends InputStreamResource {

  public MultipartFileResource(InputStream inputStream, String filename) {
    super(inputStream);
    this.filename = filename;
  }
  @Override
  public String getFilename() {
    return this.filename;
  }
}

There are a few ways to improve this situation in the framework.

1. try to “guess” the filename for all parts extending Resource; the problem is, we don’t have that information and we can only try to guess. This can also lead to new issues, since we’d be considering parts as file whereas those weren’t in the past
2. provide something that looks like a MultipartFileResource implementation and add it in the reference documentation

Could you try the workaround I told you about and confirm this works? Let me know what you think about the solutions listed here.

Thanks!