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

Validate multipart/form-data end-to-ends #2419

Closed
bterlson opened this issue Sep 13, 2023 · 8 comments
Closed

Validate multipart/form-data end-to-ends #2419

bterlson opened this issue Sep 13, 2023 · 8 comments
Assignees
Labels
docs Improvements or additions to documentation triaged:core

Comments

@bterlson
Copy link
Member

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.

@bterlson
Copy link
Member Author

Another thing to consider: allowing clients to pass a custom boundary in cases where autodetection is unreliable or undesirable.

@bterlson
Copy link
Member Author

How to specify multiple content-type application/json parts.

@markcowl markcowl added the docs Improvements or additions to documentation label Sep 18, 2023
@markcowl markcowl added this to the [2023] October milestone Sep 18, 2023
@markcowl
Copy link
Contributor

markcowl commented Sep 18, 2023

  • sample
  • docs
  • cadl-ranch test
  • openapi emitter support (if any)

est: 2

design issues:

  • client specified boundary
  • handling file names / file name required
  • how to differentiate arrays where each element is a part from an array that is meant as an array within a single part?

@mikekistler
Copy link
Member

FYI: Playground link

@timotheeguerin timotheeguerin self-assigned this Oct 3, 2023
@markcowl markcowl self-assigned this Oct 9, 2023
@markcowl markcowl changed the title Validate mutlipart/form-data end-to-ends Validate multipart/form-data end-to-ends Oct 9, 2023
@qiaozha
Copy link
Member

qiaozha commented Oct 12, 2023

Another thing to consider: allowing clients to pass a custom boundary in cases where autodetection is unreliable or undesirable.

Should boundary be a part of the content type of multipart/form-data like Content-Type: multipart/form-data; boundary=abcde12345 and typespec compiler should not generate constant content-type for multipart requests ?

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.

how to differentiate arrays where each element is a part from a part that contains an array

Kind of lost in this part, does this mean the body is an array of mixed multipart type ?

@timotheeguerin
Copy link
Member

@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)

@qiaozha
Copy link
Member

qiaozha commented Oct 12, 2023

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 ?

@markcowl
Copy link
Contributor

markcowl commented Dec 4, 2023

Complete

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
docs Improvements or additions to documentation triaged:core
Projects
None yet
Development

No branches or pull requests

5 participants