Skip to content

Match path before Content-Type in GraphQlRequestPredicates - #1486

Open
MarcoKunze-CPE wants to merge 1 commit into
spring-projects:mainfrom
MarcoKunze-CPE:fix/gh-1485-path-match-first
Open

Match path before Content-Type in GraphQlRequestPredicates#1486
MarcoKunze-CPE wants to merge 1 commit into
spring-projects:mainfrom
MarcoKunze-CPE:fix/gh-1485-path-match-first

Conversation

@MarcoKunze-CPE

Copy link
Copy Markdown

Fixes #1485

The GraphQL route predicates evaluate the request path last, after the method, Content-Type and Accept checks:

return httpMethodMatch(request, HttpMethod.POST)
        && contentTypeMatch(request, this.contentTypes)
        && acceptMatch(request, this.acceptedMediaTypes)
        && pathMatch(request, this.pattern);

Since #1145, contentTypeMatch throws UnsupportedMediaTypeStatusException for an unparseable Content-Type. Because RouterFunctionMapping evaluates the predicate during handler lookup for every request, any POST anywhere in the application with a malformed Content-Type is answered 415 — even when it does not target the GraphQL endpoint at all (details and a real-world failure mode with Vaadin heartbeats in #1485).

This change evaluates pathMatch first, so requests to other paths are never affected by Content-Type or Accept parsing. The deliberate 415 from #1145 is unchanged for requests genuinely aimed at the GraphQL path — the existing shouldRejectRequestWithInvalidContentType test still passes. Applied to both the WebMvc and the WebFlux predicate variants, with a regression test each (shouldNotRejectRequestWithInvalidContentTypeOnDifferentPath, red against the previous ordering with exactly the UnsupportedMediaTypeStatusException, green with this change; all 40 tests in both GraphQlRequestPredicatesTests classes pass).

The GraphQL route predicates evaluated the request path last, after the
method, Content-Type and Accept checks. Since the Content-Type check
throws UnsupportedMediaTypeStatusException for an unparseable header,
any POST anywhere in the application with a malformed Content-Type was
answered with 415 during handler lookup, even when the request did not
target the GraphQL endpoint at all.

Evaluate the path first so that requests to other paths are never
affected by Content-Type parsing. The 415 for unparseable Content-Type
values on the GraphQL path itself is unchanged.

Applies to both the WebMvc and the WebFlux predicate variants.

See spring-projectsgh-1485
@MarcoKunze-CPE

Copy link
Copy Markdown
Author

Transparency note: this was researched and written by an AI coding assistant (Claude) operating on my account, after we diagnosed the failure mode in our production stack. Please review it with the appropriate scrutiny, and feel free to close it if it is not relevant or does not match the project's design intent. One known caveat we leave to the team's judgement: with the path matched first, pathMatch's MATCHING_PATTERN_ATTRIBUTE side effect can now also occur for requests that fail the subsequent method/Content-Type/Accept checks (e.g. GET /graphql) — if the attribute must only be set on a full route match, a narrower fix may be preferable.

@bclozel bclozel self-assigned this Jul 31, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

status: waiting-for-triage An issue we've not yet triaged

Projects

None yet

Development

Successfully merging this pull request may close these issues.

GraphQlRequestPredicates rejects requests to non-GraphQL paths with 415 when the Content-Type is unparseable (path is matched last)

3 participants