Skip to content

feat(field): support content in response headers and show media type - #2845

Closed
ump45nose wants to merge 1 commit into
Redocly:mainfrom
ump45nose:contrib/support-for-content-in-response-headers-2632
Closed

ump45nose wants to merge 1 commit into
Redocly:mainfrom
ump45nose:contrib/support-for-content-in-response-headers-2632

Conversation

@ump45nose

Copy link
Copy Markdown

Closes #2632

Response headers that describe their schema with content instead of an inline schema
rendered nothing. The cause was in FieldModel: the schema lookup required info.in to be
set, and header objects have no in, so the lookup was skipped for every header.

Dropping that guard means content[<mime>].schema is resolved for any field that lacks an
inline schema. An inline schema still takes precedence, so existing behaviour for
parameters is unchanged.

The media type of that content mapping was already being tracked as serializationMime but
never rendered, so a reader had no way to tell which content type the shown schema belonged
to. It is now rendered below the field name, for both headers and header parameters, which is
what the issue asked for.

Testing: npx vitest run src/services/__tests__/models/FieldModel.test.ts passes, and I added
three cases to it - a header with content but no schema, a header that still uses an inline
schema, and a response header whose content has several media types. I could not run the
full yarn test suite here because the workspace's other suites need a browser/E2E setup that
is not available in this sandbox.

This pull request was prepared with the assistance of an AI coding agent and
has not yet been reviewed by a human.

Response headers that describe their schema with `content` instead of an
inline `schema` rendered nothing, because the schema lookup in FieldModel
required `info.in` to be set and header objects have no `in`. Drop that
guard so `content[<mime>].schema` is used for any field that lacks an
inline `schema`; an inline `schema` still takes precedence.

The media type of that content mapping was tracked as `serializationMime`
but never rendered, so a reader had no way to tell which content type the
schema belongs to. Render it below the field name, which is what the issue
asked for for both headers and header parameters.

Closes: Redocly#2632
@ump45nose
ump45nose requested a review from a team as a code owner October 5, 2026 00:19
@AlexVarchuk

Copy link
Copy Markdown
Collaborator

@ump45nose Thanks for the contribution, and sorry we didn't get to this in time! 馃檹

We've just shipped Redoc v3.0.0, which reworked a large part of the codebase, so older PRs no longer apply cleanly. We're closing them to keep the queue manageable. If you think this is still relevant for v3, please rebase onto main and reopen, and we'll happily review it.

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.

Support for content in Response headers on UI, add mediatype to Header Parameters

2 participants