From 7fef1add8125641b66d132b00f88e9ff635cbc81 Mon Sep 17 00:00:00 2001 From: Karen Etheridge Date: Sun, 31 May 2026 15:40:55 -0700 Subject: [PATCH] describe behaviour when deserializing a multipart with a Content-Type header --- src/oas.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/src/oas.md b/src/oas.md index a0e4cb8899..b6e3fe5cba 100644 --- a/src/oas.md +++ b/src/oas.md @@ -1729,6 +1729,8 @@ This table is based on the value to which the Encoding Object is being applied a Note that in the case of [Encoding By Name](#encoding-by-name), this value is the array item for properties of type `"array"`, and the entire value for all other types. Therefore the `array` row in this table applies only to array values inside of a top-level array when encoding by name. +When deserializing a multipart message, if a `Content-Type` header is present in the specific part, its value shall be used instead of these values. Behavior is undefined when both this header and `contentType` are defined but with different values. + | `type` | `contentEncoding` | Default `contentType` | | ---- | ---- | ---- | | [_absent_](#working-with-binary-data) | _n/a_ | `application/octet-stream` | @@ -1864,7 +1866,7 @@ Note that there are significant restrictions on what headers can be used with `m ##### Handling Multiple `contentType` Values -When multiple values are provided for `contentType`, parsing remains straightforward as the part's actual `Content-Type` is included in the document. +When multiple values are provided for `contentType`, parsing remains straightforward as the part's actual `Content-Type` is included in the document; it SHOULD match one of the media types in `contentType`, if it is present. For encoding and serialization, implementations MUST provide a mechanism for applications to indicate which media type is intended. Implementations MAY choose to offer media type sniffing ([[SNIFF]]) as an alternative, but this MUST NOT be the default behavior due to the security risks inherent in the process.