Generate better server code for response content `*/*` (dynamic Content-Type)

[brandonbloom]

Description

When an OpenAPI response uses content: {'*/*': ...} to indicate the response media type is intentionally unconstrained / dynamic / extensible, the generated server serializer currently emits code that:

1. calls converter.validateAcceptIfPresent("*/*", in: request.headerFields), and
2. sets the outgoing Content-Type to "*/*" (e.g. via setResponseBodyAsBinary(..., contentType: "*/*")).

This causes two practical problems:

• Client compatibility: it effectively forces clients to include Accept: */* just to pass validation (a client sending Accept: application/json can be rejected even though the operation is intentionally “any content”).
• Bad response header: it emits Content-Type: */*, which is not a useful concrete media type to put on the wire.

We’d like wildcard */* to mean “no static content negotiation; content type is chosen dynamically at runtime”, not “alias for application/octet-stream”.

Commit hash: ecf21fdf08d4cf30ca506bb822f5fe580e090efb

Reproduction

Minimal spec:

# openapi.yaml
openapi: 3.0.3
info:
  title: t
  version: 1.0.0
paths:
  /download:
    get:
      operationId: download
      responses:
        "200":
          description: ok
          content:
            "*/*":
              schema:
                type: string
                format: binary

Minimal generator config:

# openapi-generator-config.yaml
mode:
  - types
  - server

In the generated server serializer, the */* response path includes validateAcceptIfPresent("*/*") and emits Content-Type: */*.

Package version(s)

• swift-openapi-generator: commit ecf21fdf08d4cf30ca506bb822f5fe580e090efb
• (also involves generated code’s usage of swift-openapi-runtime Converter.validateAcceptIfPresent / setResponseBodyAsBinary)

Expected behavior

For response content type exactly */* (server serializers):

1. Skip validateAcceptIfPresent entirely.
2. Do not emit Content-Type: */*.

However, simply omitting Content-Type is not ideal; what we really want is dynamic Content-Type.

Feature request: plumb dynamic headers/media type through the generated output model for the */* case, so the handler can provide a real Content-Type at runtime.

One concrete approach would be to model the */* body case as something that carries header fields too, for example:

• case any(OpenAPIRuntime.UndocumentedPayload) (reusing an existing runtime type that carries headerFields + body), or
• a dedicated “wildcard response payload” type (e.g. { headerFields: HTTPFields, body: HTTPBody } or { contentType: String, body: HTTPBody }).

Then generated server serialization for this case would:

• not validate Accept,
• merge the payload’s header fields into response.headerFields (including a real Content-Type when provided),
• return the payload body.

Environment

$ swift --version
swift-driver version: 1.127.14.1 Apple Swift version 6.2 (swiftlang-6.2.0.19.9 clang-1700.3.19.1)
Target: arm64-apple-macosx26.0

$ uname -a
Darwin Brandons-MacBook-Pro.local 25.2.0 Darwin Kernel Version 25.2.0: Tue Nov 18 21:09:56 PST 2025; root:xnu-12377.61.12~1/RELEASE_ARM64_T6041 arm64

Additional information

• */* appears in real-world specs (e.g. Kubernetes; see prior discussion in generator issue Improve body deserialization when content-type matches multiple keys in the content map #315).
• A focused regression test could generate server code from the minimal spec above and assert the output does not contain validateAcceptIfPresent("*/*") and does not contain contentType: "*/*".

[czechboy0]

Hi @brandonbloom, thanks for filing this and the PRs. How would you like partial wildcards, like text/* to be handled?

[brandonbloom]

I should have anticipated this question :)

Both potential fixes represented by the two PRs I opened can be straightforwardly extended to handle partial wildcards. That is, loosen validation on requests, remove wildcards in responses, and optionally move towards undocumented payloads or another header-carrying response object.

Let me know if you'd like me to take on such a extension, whether it's blocking or follow-up to the PRs I opened, and how you'd like to address representation and source compatibility breakage for the header carrying response object.

[czechboy0]

Thanks @brandonbloom - yeah we'll definitely need to do something backwards compatible here, but I'm sure there is a way.

[czechboy0]

We’d like wildcard / to mean “no static content negotiation; content type is chosen dynamically at runtime”, not “alias for application/octet-stream”.

I agree that'd be the right behavior.

Now, getting there in an API-stable way will be the chunk of this work. I wonder if we should actually attach an optional contentTypeOverride: OpenAPIMIMEType? or something (from here: https://github.com/apple/swift-openapi-runtime/blob/6e88f56e6cc686b0e27b287d5d01789a08acf0d0/Sources/OpenAPIRuntime/Base/OpenAPIMIMEType.swift#L17)

[brandonbloom]

Quick link-up to related work here.

I split this into two PRs so we can make progress without forcing the bigger API decision immediately.

#860 is the conservative fix: for */* server responses, generation maps to application/octet-stream. That resolves the wildcard header behavior and keeps things straightforward to land.

#861 is a deeper follow-on, rebased on top of #860. It puts the richer wildcard modeling behind concreteWildcardResponseBodies, and with that enabled uses OpenAPIContentTypedBody + OpenAPIConcreteMIMEType so wildcard bodies carry an explicit concrete MIME type.

I also updated coverage accordingly: one test for default (flag-off) behavior and one for the flag-enabled typed path, and both focused tests pass locally.

Scope note: this work is specifically about full wildcard (*/*) responses. Partial wildcards (for example text/*) are unchanged here and should be treated as follow-up scope.