quarkusio/quarkus · error · IllegalArgumentException

The accept header value did not correspond to a valid media

Error message

The accept header value did not correspond to a valid media type

What it means

Thrown from MediaTypeMapper.selectMediaType (called from handle) as an IllegalArgumentException when none of the Accept header values on the request could be parsed while trying to select a response media type for the holder's variants. sawParseableAccept remains false after iterating all Accept entries, so it throws with the malformed-accept message. Upstream machinery typically maps this to HTTP 400.

Source

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

    public MediaType selectMediaType(ResteasyReactiveRequestContext requestContext, Holder holder) {
        MediaType selected = null;
        List<String> accepts = requestContext.getHttpHeaders().getRequestHeader(HttpHeaders.ACCEPT);
        if (!accepts.isEmpty()) {
            boolean sawParseableAccept = false;
            for (String accept : accepts) {
                // MediaTypeHelper.parseHeader skips unparseable tokens; an empty result means the header was malformed
                if (!MediaTypeHelper.parseHeader(accept).isEmpty()) {
                    sawParseableAccept = true;
                }
                Map.Entry<MediaType, MediaType> entry = holder.serverMediaType
                        .negotiateProduces(accept, null);
                if (entry.getValue() != null) {
                    selected = entry.getValue();
                    break;
                }
            }
            if (!sawParseableAccept) {
                throw new IllegalArgumentException("The accept header value did not correspond to a valid media type");
            }
        }
        if (selected == null) {
            selected = holder.mtsWithParams.get(0);
        }
        if (selected.equals(MediaType.WILDCARD_TYPE)) {
            return MediaType.APPLICATION_OCTET_STREAM_TYPE;
        }
        return selected;
    }

    private MediaType[] getProducesMediaTypes(RuntimeResource runtimeResource) {
        return runtimeResource.getProduces() == null
                ? DEFAULT_MEDIA_TYPES
                : runtimeResource.getProduces().getSortedOriginalMediaTypes();
    }

    private List<MediaType> getConsumesMediaTypes(RuntimeResource runtimeResource) {

View on GitHub (pinned to e1c734241f)

Solutions

1. Send a valid Accept header (e.g. application/json) or drop it to allow server-side default selection.
2. Fix the client's media-type negotiation configuration to emit standard type/subtype values.
3. Inspect intermediary layers (CDN, gateway) for Accept header rewriting.

Example fix

// before
request.accept("text");
// after
request.accept(MediaType.APPLICATION_JSON);

boolean anyParseable = false;
for (String t : acceptHeader.split(",")) {
    try { jakarta.ws.rs.core.MediaType.valueOf(t.trim()); anyParseable = true; break; }
    catch (IllegalArgumentException ignored) { }
}
if (!anyParseable) acceptHeader = null; // let the server choose the default

try {
    return client.get();
} catch (BadRequestException e) {
    log.error("Accept header unparseable during negotiation: {}", acceptHeader, e);
    throw e;
}

When it happens

Trigger: A request with an Accept header reaches selectMediaType on a resource with multiple @Produces variants; each Accept token fails parsing inside the selection loop; line 139 throws, e.g. 'Accept: text' or 'Accept: %%%'.

Common situations: Content negotiators in client SDKs emitting invalid Accept strings; corrupted headers from CDN/proxy layers; tests with hand-crafted header values.

Related errors

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

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