Support filename hint for client side use of ResourceDecoder

[filiphr]

With #22267 the ResourceDecoder was extended to support a filename hint that allows setting the filename of the Resource. However, this does not work correctly with using the Spring WebClient.

e.g.

ResponseEntity<ByteArrayResource> response = webClient.get("/some-resource)
    .flatMap(response -> response.toEntity(ByteArrayResource.class))
    .block();

The resource returned by this response will have null when invoking getFileName().

The reason for that is the following:

When invoking response.ToEntity(ByteArrayResource.class). We will reach:

spring-framework/spring-webflux/src/main/java/org/springframework/web/reactive/function/BodyExtractors.java

Lines 83 to 89 in 87c3bb5

	private static <T> BodyExtractor<Mono<T>, ReactiveHttpInputMessage> toMono(ResolvableType elementType) {
	return (inputMessage, context) ->
	readWithMessageReaders(inputMessage, context, elementType,
	(HttpMessageReader<T> reader) -> readToMono(inputMessage, context, elementType, reader),
	ex -> Mono.from(unsupportedErrorHandler(inputMessage, ex)),
	skipBodyAsMono(inputMessage));
	}

Which calls readToMono:

spring-framework/spring-webflux/src/main/java/org/springframework/web/reactive/function/BodyExtractors.java

Lines 206 to 211 in 87c3bb5

	private static <T> Mono<T> readToMono(ReactiveHttpInputMessage message, BodyExtractor.Context context,
	ResolvableType type, HttpMessageReader<T> reader) {
	return context.serverResponse()
	.map(response -> reader.readMono(type, type, (ServerHttpRequest) message, response, context.hints()))
	.orElseGet(() -> reader.readMono(type, message, context.hints()));

There are now 2 possibilities for invoking the reader:

1. reader.readMono(type, type, (ServerHttpRequest) message, response, context.hints()) - When the BodyExtractor.Context#serverResponse is not empty, which is the case when using ServerRequest. This case is correct.
2. reader.readMono(type, message, context.hints()) - When the BodyExtractor.Context#serverResponse is empty which is the case for a ClientResponse

Since we are using WebClient we will skip the analysis for 1. And go to 2.

The serverResponse on the extractor is set to empty here:

spring-framework/spring-webflux/src/main/java/org/springframework/web/reactive/function/client/DefaultClientResponse.java

Lines 82 to 97 in 72895f0

	this.bodyExtractorContext = new BodyExtractor.Context() {
	@Override
	public List<HttpMessageReader<?>> messageReaders() {
	return strategies.messageReaders();
	}
	@Override
	public Optional<ServerHttpResponse> serverResponse() {
	return Optional.empty();
	}
	@Override
	public Map<String, Object> hints() {
	return Hints.from(Hints.LOG_PREFIX_HINT, logPrefix);
	}
	};

When we look into the implementation of reader.readMono(type, message, context.hints()). More precisely the implementation of

spring-framework/spring-web/src/main/java/org/springframework/http/codec/HttpMessageReader.java

Line 76 in 72895f0

Mono<T> readMono(ResolvableType elementType, ReactiveHttpInputMessage message, Map<String, Object> hints);

In DecoderHttpMessageReader:

spring-framework/spring-web/src/main/java/org/springframework/http/codec/DecoderHttpMessageReader.java

Lines 102 to 106 in dbec16d

	@Override
	public Mono<T> readMono(ResolvableType elementType, ReactiveHttpInputMessage message, Map<String, Object> hints) {
	MediaType contentType = getContentType(message);
	return this.decoder.decodeToMono(message.getBody(), elementType, contentType, hints);
	}

We can see that the hints are passed as is without creating new hints based on the message.

The fix would be to also get new hints from ReactiveHttpInputMessage when reading a flux or mono without a ServerHttpResponse.

More precisely in this location:

spring-framework/spring-web/src/main/java/org/springframework/http/codec/DecoderHttpMessageReader.java

Lines 96 to 106 in dbec16d

	@Override
	public Flux<T> read(ResolvableType elementType, ReactiveHttpInputMessage message, Map<String, Object> hints) {
	MediaType contentType = getContentType(message);
	return this.decoder.decode(message.getBody(), elementType, contentType, hints);
	}
	@Override
	public Mono<T> readMono(ResolvableType elementType, ReactiveHttpInputMessage message, Map<String, Object> hints) {
	MediaType contentType = getContentType(message);
	return this.decoder.decodeToMono(message.getBody(), elementType, contentType, hints);
	}

This can be done only for the ResourceHttpMessageReader and not for DecoderHttpMessageReader

Reproducable Test case

/**
 * Unit tests for {@link ResourceHttpMessageReader}.
 *
 * @author Filip Hrisafov
 */
public class ResourceHttpMessageReaderTests extends AbstractLeakCheckingTests {

	private final ResourceHttpMessageReader reader = new ResourceHttpMessageReader();

	@Test
	void readResourceAsMono() throws IOException {
		String body = "Test resource content";
		MockServerHttpRequest request = request(body, "test.txt");
		Resource result = this.reader.readMono(ResolvableType.forClass(ByteArrayResource.class), request, null)
				.single()
				.block();

		assertThat(result).isNotNull();
		assertThat(result.getFilename()).isEqualTo("test.txt");
		try (InputStream stream = result.getInputStream()) {
			assertThat(stream).hasContent(body);
		}
	}

	private MockServerHttpRequest request(String body, String filename) {
		return request(Mono.just(stringBuffer(body)), filename);
	}

	private MockServerHttpRequest request(Publisher<? extends DataBuffer> body, String filename) {
		return MockServerHttpRequest
				.method(HttpMethod.GET, "/")
				.header(HttpHeaders.CONTENT_TYPE, MediaType.TEXT_PLAIN_VALUE)
				.header(HttpHeaders.CONTENT_DISPOSITION, ContentDisposition.builder("attachment")
						.name("file")
						.filename(filename)
						.build()
						.toString())
				.body(body);
	}

	private DataBuffer stringBuffer(String value) {
		byte[] bytes = value.getBytes(StandardCharsets.UTF_8);
		DataBuffer buffer = this.bufferFactory.allocateBuffer(bytes.length);
		buffer.write(bytes);
		return buffer;
	}

}

I am not providing a PR, because I am not sure how you would best like this to be fixed.

Edit: I submitted the issue before having the chance to clean it up.

[rstoyanchev]

Indeed we have slightly richer context on the server side where we tend to extract hints from controller method signatures. However hints could also be extracted from headers as in this case.

I experimented with this additional protected method in DecoderHttpMessageReader which can then be invoked from the decode methods with just a ReactiveHttpInputMessage:

protected Map<String, Object> getReadHints(ResolvableType elementType, ReactiveHttpInputMessage message) {
	return Hints.none();
}

This can then be overridden in ResourceHttpMessageReader and that seems to work, so I'll put this together for 5.3.

[filiphr]

Thanks a lot for doing the enhancement @rstoyanchev