Accept validation: allow +json structured syntax types

[brandonbloom]

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]

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:

swift-openapi-runtime/Sources/OpenAPIRuntime/Base/OpenAPIMIMEType.swift

Line 201 in 6e88f56

static func evaluate(

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.

[brandonbloom]

Thanks, great catch. I updated the client-side content-type matching path as suggested.

New commit makes these changes:

• Integrated RFC 6839 structured syntax suffix handling into OpenAPIMIMEType.evaluate (used by bestContentType), so values like application/problem+json are compatible with application/json.
• Preserved bestContentType priority behavior (including parameter specificity), and added explicit exact-subtype preference when multiple JSON-ish options are compatible.
• Moved structured-suffix helpers into shared MIME-type internals so server/client use the same matching primitives.
• Added tests in Test_OpenAPIMIMEType and Test_Converter+Common (including verifyContentTypeIfPresent) for suffix compatibility and selection priority.

[madsodgaard]

We are also using a backend which uses application/problem+json for returning errors as JSON. And facing the same issue of not being able to decode it.

@czechboy0 I think this might be waiting on a review, is this something you plan on looking at?