v3.2: (Split and smaller!) Support ordered multipart including streaming #4745
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This adds support for all `multipart` media types that do not have named parts, including support for streaming such media types. Note that `multipart/mixed` defines the basic processing rules for all `multipart` types, and implementations that encounter unrecognized `multipart` subtypes are required to process them as `multipart/mixed`. Therefore support for `multipart/mixed` addresses all other subtypes to some degree. This builds on the recent support for sequential media types: * `multipart/mixed` and similar meet the definition for a sequential media type, requiring it to be modeled as an array. This does use an expansive definition of "repeating the same structure", where the structure is literally any content with a media type. * As a sequential media type, it also supports `itemSchema` * Adding a parallel `itemEncoding` is the obvious solution to `multipart/mixed` streams requiring an Encoding Object * We have regularly received requests to support truly mixed `multipart/mixed` payloads, and previously claimed such support from 3.0.0 onwards, without actually supporting it. Adding `prefixEncoding` along with `itemEncoding` supports this use case with a clear parallel to `prefixItems`, which is the schema construct needed to support this case. * There is no need for a `prefixSchema` field because the streaming use case requires a repetition of the same schema for each item. Therefore all mixed use cases can use `schema` and `prefixItems`
handrews
added
the
media and encoding
This was referenced Jun 21, 2025
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
**NOTE: This is just the new fields and their description, schema, and schema tests, with several things removed: 1.) the elaborate rules for determining type, which are now in PR #4743, 2.) the examples, which are in PR #4746 so they can be discussed in-depth and updated based on the pending Example Object changes. The contents of this PR are otherwise identical to #4589.
This adds support for all
multipartmedia types that do not have named parts, including support for streaming such media types. Note thatmultipart/mixeddefines the basic processing rules for allmultiparttypes, and implementations that encounter unrecognizedmultipartsubtypes are required to process them asmultipart/mixed. Therefore support formultipart/mixedaddresses all other subtypes to some degree.This builds on the recent support for sequential media types:
multipart/mixedand similar meet the definition for a sequential media type, requiring it to be modeled as an array. This does use an expansive definition of "repeating the same structure", where the structure is literally any content with a media type.itemSchemaitemEncodingis the obvious solution tomultipart/mixedstreams requiring an Encoding Objectmultipart/mixedpayloads, and previously claimed such support from 3.0.0 onwards, without actually supporting it. AddingprefixEncodingalong withitemEncodingsupports this use case with a clear parallel toprefixItems, which is the schema construct needed to support this case.prefixSchemafield because the streaming use case requires a repetition of the same schema for each item. Therefore all mixed use cases can useschemaandprefixItems