Affects: 5.3.12

I'm using Spring to integrate towards a third party API. This API validates the Content-Type header and requires it to be exactly application/json;profile=https://se.digitalreceipts.net/schemas/json/retail/v1.0

When executing this request an exception is thrown:

org.springframework.http.InvalidMediaTypeException: Invalid mime type "application/json;profile=https://se.digitalreceipts.net/schemas/json/retail/v1.0": Invalid token character ':' in token "https://se.digitalreceipts.net/schemas/json/retail/v1.0" at org.springframework.http.MediaType.parseMediaType(MediaType.java:620) ~[spring-web-5.3.10.jar:5.3.10]

The content type is parsed to a MimeType and the parameter is validated, failing on colon and forward slash. I understand that this parameter might not follow the specification, but as it is a sendable value (required by some third party API:s) there should be a way to send it if necessary. Currently there is no way for me to use the WebClient and this parameter.

Comment From: happyWilliam0

Hi, I tested this issue in my project, but it didn't appear. Spring Cannot use any value as parameter to the Content-Type header for the WebClient Below is the response Spring Cannot use any value as parameter to the Content-Type header for the WebClient Please confirm whether there is a problem with my test method. Thx. @Kristoffer-Smedlund

Comment From: Kristoffer-Smedlund

Hi, I tested this issue in my project, but it didn't appear. Spring Cannot use any value as parameter to the Content-Type header for the WebClient Below is the response Spring Cannot use any value as parameter to the Content-Type header for the WebClient Please confirm whether there is a problem with my test method. Thx. @Kristoffer-Smedlund

Hi, Yes. I'm using the Spring reactive WebClient to send requests.

Comment From: bclozel

I haven't found a way to work around this Content-Type validation with WebClient. I don't think this is possible right now, nor we could easily introduce an escape hatch for that. As this media type is illegal, we shouldn't deeply disrupt the existing architecture to enable such a use case.

I'm closing this issue as declined as a result. This is probably not ideal, but I'd suggest using a lower level HTTP client for this particular endpoint until it accepts valid media types.