Skip to content

Conversation

@brandonbloom
Copy link

@brandonbloom brandonbloom commented Jan 18, 2026

Motivation

Converter.validateAcceptIfPresent validates the request Accept header against the server’s chosen response Content-Type. Today this is strict (exact type/subtype match, type/*, or */*), which means a common real-world pairing fails:

  • Request: Accept: application/json
  • Error response (RFC 7807 Problem Details): Content-Type: application/problem+json

HTTP content negotiation does not standardize suffix-aware matching for structured syntax suffixes, so treating application/json as compatible with application/*+json is a server policy choice. However, it is widely expected in practice (especially around Problem Details), and the strict behavior forces downstream servers to add middleware workarounds (e.g. mutate Accept or avoid emitting application/problem+json) just to prevent a runtime error.

Modifications

  • Extend OpenAPIMIMEType.satisfies(acceptValue:) to add an additional compatibility rule for structured syntax suffixes:
    • Treat Accept: application/json as compatible with Content-Type: application/problem+json (and other application/*+json types with +json).
    • Treat Accept: application/*+json as compatible with application/problem+json (and also application/json).
  • Add focused unit coverage in Tests/OpenAPIRuntimeTests/Conversion/Test_Converter+Server.swift under testValidateAccept.

Result

The runtime’s Accept validation no longer throws for common JSON-based structured media types like application/problem+json when clients send Accept: application/json, reducing downstream middleware/workarounds while keeping existing exact and wildcard matching behavior.

Test Plan

  • swift test --filter Test_ServerConverterExtensions.testValidateAccept

@czechboy0
Copy link
Contributor

I didn't realize the suffix behavior is defined in an RFC, thanks for sharing! I agree we should improve this and handle application/foo+json as JSON.

Now, I think we also need to adjust the client response content type checking logic here:

We'll need to be careful when multiple JSON-ish content types are specified, the method linked above does create a specific priority based on parameters, and so on. So we should integrate the suffix handling there.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants