Skip to content

Support contentEncoding for OpenAPI 3.1 schemas (parse + ContentEncodingIn30 rule) - #206

Open
takayamaki wants to merge 4 commits into
ota42y:masterfrom
takayamaki:pr15-contentencoding
Open

takayamaki wants to merge 4 commits into
ota42y:masterfrom
takayamaki:pr15-contentencoding

Conversation

@takayamaki

Copy link
Copy Markdown
Contributor

Continuing the OpenAPI 3.1 work from #152.

OpenAPI 3.1 adopts JSON Schema 2020-12, which brings the contentEncoding annotation.
It records how a string carrying binary data is encoded (base64, base32, quoted-printable, ...).
3.0 has no keyword for this.

This PR adds parse support and version-mismatch detection.
It is the sibling of #204 (contentMediaType).

Parse layer

contentEncoding is parsed as a plain value and exposed as an accessor on Schema:

schema.contentEncoding # => "base64"

Following the permissive-parse strategy agreed in #152,
the parse layer accepts contentEncoding regardless of the declared OpenAPI version.

contentEncoding is an annotation: it describes the payload rather than constraining it,
so there is no runtime validation to add here.

SpecValidator rule

ContentEncodingIn30 reports a violation for each schema in a 3.0 document that uses contentEncoding:

OpenAPIParser.load(
  'spec.yaml',
  strict_specification_version: :warn,
)
# [ContentEncodingIn30] #/components/schemas/Attachment — `contentEncoding` is a 3.1 addition (from JSON Schema 2020-12); 3.0 has no equivalent

Detection inspects raw_schema key presence,
so it fires on any declared encoding value.

`contentEncoding` on a 3.0 document warns and raises (JSON Schema
2020-12 annotation with no 3.0 equivalent); the same keyword on a 3.1
document stays clean.
@takayamaki
takayamaki marked this pull request as ready for review September 12, 2026 01:17
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.

1 participant