Server: special-case */* responses (skip Accept validation, don’t emit Content-Type: */*)

[brandonbloom]

Motivation

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

• calls converter.validateAcceptIfPresent("*/*", in: request.headerFields), which effectively forces clients to include Accept: */*, and
• emits Content-Type: */* (via setResponseBodyAsBinary(..., contentType: "*/*")).

Both behaviors are problematic in practice.

This PR is a safe first step: it fixes the immediate incorrect strictness and avoids emitting an invalid/meaningless response Content-Type, while keeping the generated public API unchanged.

Related: #859 (kept open; follow-up can explore a richer, potentially source-breaking solution to plumb dynamic Content-Type).

Modifications

• In server response serialization, special-case response content type exactly */* to:
  • skip validateAcceptIfPresent, and
  • assign the HTTPBody directly without setting Content-Type: */*.
• Add a snippet-based regression test verifying the generated server code for a */* response does not contain validateAcceptIfPresent("*/*") and does not contain contentType: "*/*".

Result

Generated servers no longer reject requests that omit Accept: */* for wildcard responses, and no longer emit Content-Type: */*.

Test Plan

• swift test

[czechboy0]

Hi @brandonbloom,

Generated servers no longer reject requests that omit Accept: /

It's surprising that it'd reject it, the idea is that if the client doesn't send an Accept header at all, the validation is skipped: https://github.com/apple/swift-openapi-runtime/blob/6e88f56e6cc686b0e27b287d5d01789a08acf0d0/Sources/OpenAPIRuntime/Conversion/Converter%2BServer.swift#L51

Are you seeing a different behavior? Is the server rejecting requests that completely omit Accept?

Regarding the response Content-Type header, I still think we should send one. Maybe sending application/octet-stream is more appropriate, considering we're just piping through raw bytes without knowing what they are? I agree that sending Content-Type: */* isn't right.