Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Is it possible to indicate the requiredness of a multipart/form-data's request's filename directive? #4442

Open
TomerAberbach opened this issue Mar 15, 2025 · 6 comments
Labels
media and encoding Issues regarding media type support and how to encode data (outside of query/path params) param serialization Issues related to parameter and/or header serialization
Milestone

Comments

@TomerAberbach
Copy link

As far as I can tell, the required property in the OpenAPI spec can be used to specify that an entire multipart/form-data part is required, but it cannot be used to indicate whether the filename directive is required.

This would be pretty useful since some multipart/form-data endpoints require the filename directive while others do not. If OpenAPI allowed specifying those semantics, then that could be used in various generators that consume OpenAPI (e.g. an SDK generator could check whether the end-user supplied a filename if it's required).

@LasneF
Copy link
Member

LasneF commented Mar 19, 2025

You are right
as of today there is no way no manipulate the content disposition , this would be something to add in OAS 3.2 or 3.+

adding RFC link for the record (https://www.rfc-editor.org/rfc/rfc7578#section-4.3)

@TomerAberbach
Copy link
Author

Thanks for confirming!

Is there anything I can do to help with getting it into the spec?

@handrews handrews added this to the v3.3.0 milestone Mar 19, 2025
@handrews
Copy link
Member

@TomerAberbach this woul likely go into 3.3 as part of a larger revamp/streamlining of data modeling. The way that form and/or multipart data is managed is a complex and rickety set of features that weren't all designed together, so we neeed to do something bigger than will fit in the 3.2 time frame. See #4210 for release planning details, as well as #1502 for some history on data modeling problems.

Unfortunately, revamping data modeling is a bit of a big/historically burdened topic to just jump on immediately.

@handrews handrews added param serialization Issues related to parameter and/or header serialization media and encoding Issues regarding media type support and how to encode data (outside of query/path params) labels Mar 19, 2025
@TomerAberbach
Copy link
Author

Cool, that makes sense!

I'm happy to get involved here if you think it'd be helpful, but if you already have a handle on this revamp, then I'll leave it to you :)

@handrews
Copy link
Member

@TomerAberbach we probably won't get to it until the summer, as we need to get 3.2 out the door (or at least mostly finished) first.

@TomerAberbach
Copy link
Author

Noted. Let me know if you need any more info from me when the time comes

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
media and encoding Issues regarding media type support and how to encode data (outside of query/path params) param serialization Issues related to parameter and/or header serialization
Projects
None yet
Development

No branches or pull requests

3 participants