quarkusio/quarkus · error · NotSupportedException

The content-type header value did not correspond to a valid

Error message

The content-type header value did not correspond to a valid media type

What it means

RESTEasy Reactive throws this NotSupportedException (HTTP 415) when the request's Content-Type header cannot be parsed as a valid media type. In validateConsumes, MediaTypeHelper.valueOf(contentType) throws IllegalArgumentException for syntactically invalid values, which is caught and rethrown as this NotSupportedException. This is a client-side syntax error in the header, distinct from a valid type that merely does not match @Consumes.

Source

Thrown at independent-projects/resteasy-reactive/server/runtime/src/main/java/org/jboss/resteasy/reactive/server/handlers/HandlerMediaTypeUtil.java:39

    private static final String INVALID_ACCEPT_HEADER_MESSAGE = "The accept header value did not match the value in @Produces";
    private static final String MALFORMED_ACCEPT_HEADER_MESSAGE = "The accept header value did not correspond to a valid media type";

    // according to the spec we need to return HTTP 415 when content-type header doesn't match what is specified in @Consumes
    // HttpMethod being null means this is a sub resource locator method. The handler chain of the sub resource has to match the content-type header
    static void validateConsumes(RequestMapper.RequestMatch<RuntimeResource> target,
            ResteasyReactiveRequestContext requestContext) {
        if (target.value.getHttpMethod() != null && !target.value.getConsumes().isEmpty()) {
            String contentType = (String) requestContext.getHeader(HttpHeaders.CONTENT_TYPE, true);
            if (contentType != null) {
                try {
                    if (MediaTypeHelper.getFirstMatch(
                            target.value.getConsumes(),
                            Collections.singletonList(MediaTypeHelper.valueOf(contentType))) == null) {
                        throw new NotSupportedException("The content-type header value did not match the value in @Consumes");
                    }
                } catch (IllegalArgumentException e) {
                    throw new NotSupportedException("The content-type header value did not correspond to a valid media type");
                }
            }
        }
    }

    // according to the spec we need to return HTTP 406 when Accept header doesn't match what is specified in @Produces.
    // A fully unparseable Accept header is a client syntax error and returns HTTP 400 instead.
    // HttpMethod being null means this is a sub resource locator method. The handler chain of the sub resource has to match the accept header
    static void validateProduces(RequestMapper.RequestMatch<RuntimeResource> target,
            ResteasyReactiveRequestContext requestContext) {
        if (target.value.getHttpMethod() != null && target.value.getProduces() != null) {
            // there could potentially be multiple Accept headers and we need to response with 406
            // if none match the method's @Produces
            List<String> accepts = (List<String>) requestContext.getHeader(HttpHeaders.ACCEPT, false);
            if (!accepts.isEmpty()) {
                boolean hasAtLeastOneMatch = false;
                boolean sawParseableAccept = false;
                for (int i = 0; i < accepts.size(); i++) {

View on GitHub (pinned to e1c734241f)

Solutions

Inspect the outgoing request and correct the Content-Type header to a well-formed type/subtype value such as application/json or text/plain.
Validate header construction in the client code — ensure no empty parameters, missing slashes, or unrendered template variables.
If a proxy/gateway rewrites headers, fix its header manipulation configuration.

Example fix

// before (client)
request.setHeader("Content-Type", "json");
// after
request.setHeader("Content-Type", "application/json");

Defensive patterns

Strategy: validation

Validate before calling

// validate before sending
try {
    jakarta.ws.rs.core.MediaType.valueOf(contentType);
} catch (IllegalArgumentException e) {
    throw new IllegalStateException("Malformed Content-Type header: " + contentType, e);
}

Try / catch

try {
    return client.post(entity);
} catch (BadRequestException | NotSupportedException e) {
    log.error("Check Content-Type header format", e);
    throw e;
}

Prevention

Use MediaType constants instead of raw strings when building headers.
Never build header values from unvalidated user input or unrendered templates.
Add a client-side unit test asserting well-formed headers.

When it happens

Trigger: A request to a @Consumes-annotated endpoint carries a Content-Type header that MediaTypeHelper.valueOf cannot parse — e.g. 'Content-Type: application/json; charset=' (empty parameter), 'Content-Type: json' (no type/subtype), or other malformed header values that fail MediaTypeHeaderDelegate parsing.

Common situations: Hand-rolled HTTP clients or curl invocations with typo'd headers; proxies or middleware rewriting/duplicating the Content-Type header; template placeholders left unrendered (e.g. 'Content-Type: ${contentType}'); charset parameter with missing value.

Related errors

AI-assisted analysis of quarkusio/quarkus@e1c734241f (2026-09-05). Data as JSON: /api/errors/fe2e9d7c189ba4cb. Report an issue: GitHub.