-
Notifications
You must be signed in to change notification settings - Fork 222
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
Validate multipart/form-data end-to-ends #2419
Comments
Another thing to consider: allowing clients to pass a custom boundary in cases where autodetection is unreliable or undesirable. |
How to specify multiple content-type application/json parts. |
est: 2 design issues:
|
FYI: Playground link |
Should boundary be a part of the content type of multipart/form-data like Another question is, I feel like content-type and content-disposition are some kind of things each languages' core libraries should support during serialization and deserilization ? Though we probably need the information about the content-type of each parts.
Kind of lost in this part, does this mean the body is an array of mixed multipart type ? |
@qiaozha I think custom boundary by the user is not something we have designed yet so I would hold off on any assumption of what the user could do to make it work. Same for question 2 this is still pending some design. For the last question if we are working with part that are basically an array how do we know this is meant to be an array of part vs just a regular array (more design needed) |
Thanks @timotheeguerin for sharing this. Just a little curious, is it a blocker for openai non branding work ? should we support custom boundary and content-type for different parts in openai's case ? |
part of microsoft#2419 https://tspwebsitepr.z22.web.core.windows.net/prs/2667/next/standard-library/http/multipart.html --------- Co-authored-by: Mark Cowlishaw <markcowl@microsoft.com>
Complete |
Multipart/form-data endpoints are super common, but we don't have much coverage for them at this point and it's likely things are missing or non-optimal (#2370 is an example).
At a minimum, we need to support being explicit about the headers for each part, content-type and content-disposition in particular.
We may also want to consider going beyond OpenAPI and being explicit and treating filename and name as explicit parameters/return types so we can express whether these are optional or required.
The text was updated successfully, but these errors were encountered: