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

Thrown as a JAX-RS NotSupportedException when the request's Content-Type header does not match any media type declared via @Consumes on the targeted (sub-)resource method. For sub-resources this check mimics ClassRoutingHandler since routing happened on the locator. The server rejects the request before deserialization.

Source

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

    @Override
    public void handle(ResteasyReactiveRequestContext requestContext) throws Exception {
        requestContext.requireCDIRequestScope();
        MediaType effectiveRequestType = null;
        Object requestType = requestContext.getHeader(HttpHeaders.CONTENT_TYPE, true);
        if (requestType != null) {
            try {
                effectiveRequestType = MediaTypeHelper.valueOf((String) requestType);
            } catch (Exception e) {
                log.debugv("Incorrect media type", e);
                throw new WebApplicationException(Response.status(Response.Status.BAD_REQUEST).build());
            }

            // We need to verify media type for sub-resources, this mimics what is done in {@code ClassRoutingHandler}
            if (MediaTypeHelper.getFirstMatch(
                    acceptableMediaTypes,
                    Collections.singletonList(effectiveRequestType)) == null) {
                throw new NotSupportedException("The content-type header value did not match the value in @Consumes");
            }
        } else if (!acceptableMediaTypes.isEmpty()) {
            effectiveRequestType = acceptableMediaTypes.get(0);
        } else {
            effectiveRequestType = MediaType.APPLICATION_OCTET_STREAM_TYPE;
        }
        List<MessageBodyReader<?>> readers = serialisers.findReaders(null, type, effectiveRequestType, RuntimeType.SERVER);
        if (readers.isEmpty()) {
            log.debugv("No matching MessageBodyReader found for type {0} and media type {1}", type, effectiveRequestType);
            throw new NotSupportedException();
        }
        for (MessageBodyReader<?> reader : readers) {
            if (isReadable(reader, requestContext, effectiveRequestType)) {
                Object result;
                ReaderInterceptor[] interceptors = requestContext.getReaderInterceptors();
                try {
                    try {
                        if (interceptors == null) {

View on GitHub (pinned to e1c734241f)

Solutions

Send a Content-Type header matching one of the method's @Consumes values
Widen @Consumes on the resource method (e.g. add the media type or MediaType.WILDCARD)
Check the sub-resource class's @Consumes, not just the locator method
Fix client library defaults that set an unexpected Content-Type

Example fix

// before
@POST
@Consumes(MediaType.APPLICATION_JSON)
public String create(String body) { ... }
// client sends Content-Type: text/plain
// after: client sends
// Content-Type: application/json
// or widen:
@Consumes({MediaType.APPLICATION_JSON, MediaType.TEXT_PLAIN})

Defensive patterns

Strategy: validation

Validate before calling

MediaType ct = MediaType.valueOf(request.getHeader("Content-Type"));
boolean ok = consumes.stream().anyMatch(c -> c.isCompatible(ct));

Try / catch

try { return resource.post(entity); } catch (NotSupportedException e) { log.warn("Content-Type not in @Consumes: {}", e.getMessage()); return Response.status(415).build(); }

Prevention

Set explicit Content-Type on every client request
Keep @Consumes permissive unless validation requires narrowing
Check sub-resource classes' @Consumes too, not just locators

When it happens

Trigger: Client sends a Content-Type (e.g. application/xml) that no @Consumes value on the resource method matches; calling a sub-resource whose @Consumes differs from what routing matched; sending no Content-Type when the method requires one.

Common situations: Clients posting form data with wrong content type (text/plain instead of application/x-www-form-urlencoded); API version changes adding @Consumes restrictions; sub-resource locators narrowing acceptable types.

Related errors

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