You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Is it possible to indicate the requiredness of a multipart/form-data's request's filename directive? #4442
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).
@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.
For what it's worth, even if that technically constrains it, it wouldn't have worked for my original use-case because it's not easy for tooling to interpret what an arbitrary pattern is trying to do semantically (unless you look for exactly the pattern you have there, which would be hacky and brittle)
Yes, indeed, trying to serialize a message by trying to decipher a regex in a schema is not terribly usable. It would tell you if you serialized it incorrectly (by validating the resulting serialized request against the OAD), but you have to get there first.
The real solution is to use a new syntax in the header definition that describes parameters in a generic way, which we've started to talk about (see OAI/sig-moonwalk#108), and MAY appear in 3.3 (but there is no commitment yet).
Activity
LasneF commentedon 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 commentedon Mar 19, 2025
Thanks for confirming!
Is there anything I can do to help with getting it into the spec?
handrews commentedon Mar 19, 2025
@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.
TomerAberbach commentedon Mar 19, 2025
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 commentedon Mar 19, 2025
@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 commentedon Mar 19, 2025
Noted. Let me know if you need any more info from me when the time comes
baywet commentedon Sep 25, 2025
Kind of related to #2458 and #2342
karenetheridge commentedon Aug 3, 2026
You can do it today with a regex on the header string:
TomerAberbach commentedon Aug 4, 2026
For what it's worth, even if that technically constrains it, it wouldn't have worked for my original use-case because it's not easy for tooling to interpret what an arbitrary pattern is trying to do semantically (unless you look for exactly the pattern you have there, which would be hacky and brittle)
karenetheridge commentedon Aug 4, 2026
Yes, indeed, trying to serialize a message by trying to decipher a regex in a schema is not terribly usable. It would tell you if you serialized it incorrectly (by validating the resulting serialized request against the OAD), but you have to get there first.
The real solution is to use a new syntax in the
headerdefinition that describes parameters in a generic way, which we've started to talk about (see OAI/sig-moonwalk#108), and MAY appear in 3.3 (but there is no commitment yet).