Skip to content

Commit 0a5b864

Browse files
encoding headers are not needed for serializing an array
We have the names for each part, as the parsed data uses the format: [ { <name>: <value> }, { <name>: <value> }, ... ]
1 parent 2f7b55b commit 0a5b864

1 file changed

Lines changed: 2 additions & 2 deletions

File tree

src/oas.md

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -1400,8 +1400,8 @@ The `itemEncoding` field can also be used with `itemSchema` to support streaming
14001400

14011401
##### Additional Encoding Approaches
14021402

1403-
The `prefixEncoding` field can be used with any `multipart` content to require a fixed part order.
1404-
This includes `multipart/form-data`, for which the Encoding Object's `headers` field MUST be used to provide the `Content-Disposition` and part name, as no property names exist to provide the names automatically.
1403+
The `prefixEncoding` and/or `itemEncoding` fields, and/or usage of a [`schema` indicating an array type](#non-json-data) (or `itemSchema`), can be used with any `multipart` content to require a fixed part order.
1404+
This includes `multipart/form-data`, in which the property name of each item are used to populate the `Content-Disposition` headers with the part name.
14051405

14061406
Prior versions of this specification advised using the [`name` parameter](https://www.rfc-editor.org/rfc/rfc7578#section-4.2) of the `Content-Disposition: form-data` header of each part with `multipart` media types other than `multipart/form-data` in order to work around the limitations of the `encoding` field.
14071407
Implementations MAY choose to support this workaround, but as this usage is not common, implementations of non-`form-data` `multipart` media types are unlikely to support it.

0 commit comments

Comments
 (0)