WebClient: Explicit Content-Type application/octet-stream is overwritten

[othi]

Affected version: 6.1.11

The API I'm consuming requires the Content-Type header to be application/octet-stream for certain binary payloads.

The Content-Type is set explicitly using RequestBodySpec.contentType() but it is later overwritten in this method:

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

Lines 165 to 176 in 29dce74

	private static MediaType getResourceMediaType(
	@Nullable MediaType mediaType, Resource resource, Map<String, Object> hints) {
	if (mediaType != null && mediaType.isConcrete() && !mediaType.equals(MediaType.APPLICATION_OCTET_STREAM)) {
	return mediaType;
	}
	mediaType = MediaTypeFactory.getMediaType(resource).orElse(MediaType.APPLICATION_OCTET_STREAM);
	if (logger.isDebugEnabled() && !Hints.isLoggingSuppressed(hints)) {
	logger.debug(Hints.getLogPrefix(hints) + "Resource associated with '" + mediaType + "'");
	}
	return mediaType;
	}

This is unintuitive behaviour and not configurable. To circumvent this, I have to rename the file to an extension not present in spring-web/src/main/resources/org/springframework/http/mime.types so my explicitly set header is respected.

To reproduce, here is a function that sets the content type of the request:

    public void test() throws IOException {
        File f = File.createTempFile("test", ".pdf");

        WebClient webClient = WebClient.create();
        RequestBodySpec builder = webClient.method(HttpMethod.POST).uri("http://localhost:12458");
        builder.contentType(MediaType.APPLICATION_OCTET_STREAM);
        builder.body(BodyInserters.fromValue(new FileSystemResource(f)));
        builder.retrieve().toBodilessEntity().block();
    }

Resulting request using netcat:

me@dev:~$ nc -l 12458
POST / HTTP/1.1
accept-encoding: gzip
user-agent: ReactorNetty/1.1.9
host: localhost:12458
accept: */*
Content-Type: application/pdf   <---------
content-length: 0

Expected result:

Content-Type: application/octet-stream

Thanks

[imvtsl]

@bclozel
Is it okay if I work on this issue?

[bclozel]

Sorry for the delayed feedback.

I'm not sure we can support this specific use case without undoing the mime type detection, which is widely used. I think application/octet-stream is assumed as the default for many client libraries, hence our check.

Have you considered using a custom media type like application/octet-stream;force=true or something equivalent? An additional parameter would skip this check.

[othi]

That does work in my case but it still seems unfortunate to have to do that.

Would it not be acceptable to you to have the setter set a flag to indicate that it was called, making the choice of the content-type explicit? I understand that mime type detection is a helpful feature, but if the setter is called on the builder, surely the user did not want that choice to be overridden?

[bclozel]

Thanks for the proposal, but I think we're going to stick with the current behavior.

The ResourceHttpMessageWriter is trying to detect a more precise media type, and here it does. I'm not sure what the requirement is here, maybe because the remote server doesn't support anything but application/octet-stream? In this case, if the filename is not meant to be used at all as source of truth, I would suggest using a Resource implementation that does not expose the filename information. This would also work and probably better reflect the use case you're facing: the file information is not relevant, only the content bytes.