Support for `multipart/mixed` (and possibly better `multipart/*` support in general) about openapi-specification HOT 5 OPEN

It's also worth noting that when uploading multiple files for a form field with multipart/form-data, RFC 7578 requires having multiple parts with the same name, which can't be modeled by the current "treat it as a JSON object" approach.

from openapi-specification.

A big missing piece from the multipart/mixed RFC is the ability to define the body parts in the same way form-data uses content-disposition header.

Because the RFC is so old, and was originally for email messaging, apparently they didn't have a need to identify the body parts and the form-data RFC didn't address the /mixed RFC when updates were made for the new header.

if we could depend on this same header, I think it would help quite a lot to define mixed bodies with OAS, with the same syntax as form-data and x-www-urlencoded bodies

from openapi-specification.

EDIT: guess I should have read your link.

Another multipart option missing is the ability to send multiple files in a single form field.

It should be a form-data payload with a nested multipart body with individual parts for each file. There is no way to define a nested multipart payload.

This is as far as I can get with it. But no way to define the nested body parts if I were to send multiple file types

requestBody:
  content:
    'multipart/form-data':
      schema:
       name:
         type: string
       file:
         type: string
         format: binary
      encoding:
        name:
          headers:
            content-disposition:
              schema:
                type: string
          contentType: 'application/json'
        file:
          headers:
            content-disposition:
              schema:
                type: string
          contentType: 'multipart/mixed'

from openapi-specification.

@jeremyfiel I know that multipart/mixed and similar MIME-derived formats explicitly allow nesting.

I noticed that the most recent multipart/form-data RFC, RFC 7578, deprecates the nesting in favor of multiple parts with the same name. According to the RFC's appendix, the nested approach wasn't known to be implemented but I assume you have an implementation that does it.

from openapi-specification.

@jeremyfiel I know that multipart/mixed and similar MIME-derived formats explicitly allow nesting.

I noticed that the most recent multipart/form-data RFC, RFC 7578, deprecates the nesting in favor of multiple parts with the same name. According to the RFC's appendix, the nested approach wasn't known to be implemented but I assume you have an implementation that does it.

I'm not entirely sure we have a nested implementation, but we do heavily use /mixed payloads because we like having JSON metadata along side a file representation.

from openapi-specification.