quarkusio/quarkus · error · NotSupportedException

The content-type header value did not match the value in @Co

Error message

The content-type header value did not match the value in @Consumes

What it means

In the MediaTypeMapper handler (used for resources with multiple methods distinguished by media types), this NotSupportedException (HTTP 415) is thrown when the request's Content-Type cannot be found in resourcesByConsumes, including after falling back to the wildcard entry. It means no resource method variant is registered that can consume the request's content type. Like error 3650 but raised at MediaTypeMapper.handle time rather than during initial validation.

Source

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

        for (Holder holder : resourcesByConsumes.values()) {
            holder.setupServerMediaType();
        }
    }

    @Override
    public void handle(ResteasyReactiveRequestContext requestContext) throws Exception {
        // find the best matching consumes type. Note that the arguments are reversed from their definition
        // of desired/provided, but we do want the result to be a media type we consume, since that's how we key
        // our methods, rather than the single media type we get from the client. This way we ensure we get the
        // best match.
        MediaType consumes = MediaTypeHelper.getBestMatch(contentTypeFromRequest(requestContext), consumesTypes);
        Holder selectedHolder = resourcesByConsumes.get(consumes);
        // if we haven't found anything, try selecting the wildcard type, if any
        if (selectedHolder == null) {
            selectedHolder = resourcesByConsumes.get(MediaType.WILDCARD_TYPE);
        }
        if (selectedHolder == null) {
            throw new NotSupportedException("The content-type header value did not match the value in @Consumes");
        }
        RuntimeResource selectedResource;
        if (selectedHolder.mtWithoutParamsToResource.size() == 1) {
            selectedResource = selectedHolder.mtWithoutParamsToResource.values().iterator().next();
        } else {
            MediaType produces;
            try {
                produces = selectMediaType(requestContext, selectedHolder);
            } catch (IllegalArgumentException e) {
                // Accept contained no parseable media type tokens
                throw new WebApplicationException(Response.status(Response.Status.BAD_REQUEST).build());
            } catch (Exception e) {
                // there is TCK testing this, but some of the legacy RESTEasy tests do expect the result to be 400
                throw new WebApplicationException(Response.status(Response.Status.BAD_REQUEST).build());
            }
            requestContext.setResponseContentType(produces);
            MediaType key = produces;
            if (!key.getParameters().isEmpty()) {

View on GitHub (pinned to e1c734241f)

Solutions

1. Send the request with a Content-Type matching one of the endpoint's registered @Consumes values.
2. Add a resource method (or extend the existing one's @Consumes) covering the missing media type.
3. Check that any header-rewriting proxy isn't converting the Content-Type to something unexpected.

Example fix

// before
@POST
@Consumes(MediaType.APPLICATION_JSON)
public Response create(String body) { ... }
// after
@POST
@Consumes({MediaType.APPLICATION_JSON, MediaType.TEXT_PLAIN})
public Response create(String body) { ... }

// verify the endpoint accepts the content type before posting
java.util.Set<String> consumed = java.util.Set.of("application/json");
if (!consumed.contains(contentType)) {
    throw new IllegalStateException("Endpoint does not accept " + contentType);
}

try {
    return client.post(entity);
} catch (NotSupportedException e) {
    log.error("No @Consumes variant for {} — check server mappings", contentType, e);
    throw e;
}

When it happens

Trigger: A request hits a resource handled by MediaTypeMapper; handle() looks up resourcesByConsumes.get(consumes) for the parsed request content type, gets null, also gets null for MediaType.WILDCERD_TYPE fallback, and throws at line 72 — e.g. sending Content-Type: text/plain where the mapper only has application/json and wildcard variants are absent.

Common situations: Clients posting a different body format than any registered @Consumes variant; adding a new @Consumes variant but forgetting to redeploy/register it; content-type negotiation misconfiguration between gateway-rewritten headers and server mappings.

Related errors

• The content-type header value did not match the value in @Co
• The content-type header value did not correspond to a valid
• The content-type header value did not correspond to a valid
• The accept header value did not match the value in @Produces
• The accept header value did not correspond to a valid media

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