-
-
Notifications
You must be signed in to change notification settings - Fork 230
Array of files in multipart/form-data is not handled correctly #692
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
Comments
BTW, I'd be happy to contribute a fix for this if this is indeed a bug. But wanted to first verify to see if there was a reason that the list of files was being serialized as json. |
I'm facing the same issue. Any plans to merge the fix? |
This will work today if you have a schema like this: "schema": {
"type": "array",
"items": {
"type": "string",
"format": "binary"
}
} You're right though, that the object format does need to be supported so that explicit file names can be set via the object keys. This probably needs to be a different object (not Also, for completeness, the encoding object will give better control over how this works. For an initial fix, though, using all of the defaults it defines (e.g., arrays inherit, I'm totally open to a PR implementing a solution here! |
As described in #692 arrays of files are not handled correctly, if they are part of multipart/form-data. This is fixed in this PR by letting `to_multipart` return a `List[Tuple[str, Any]]` instead of a `Dict[str, Any]`. --------- Co-authored-by: Dylan Anthony <dbanty@users.noreply.github.com> Co-authored-by: Dylan Anthony <43723790+dbanty@users.noreply.github.com>
> [!IMPORTANT] > Merging this pull request will create this release ## Breaking Changes - Raise minimum httpx version to 0.23 ### Removed ability to set an array as a multipart body Previously, when defining a request's body as `multipart/form-data`, the generator would attempt to generate code for both `object` schemas and `array` schemas. However, most arrays could not generate valid multipart bodies, as there would be no field names (required to set the `Content-Disposition` headers). The code to generate any body for `multipart/form-data` where the schema is `array` has been removed, and any such bodies will be skipped. This is not _expected_ to be a breaking change in practice, since the code generated would probably never work. If you have a use-case for `multipart/form-data` with an `array` schema, please [open a new discussion](https://github.com/openapi-generators/openapi-python-client/discussions) with an example schema and the desired functional Python code. ### Change default multipart array serialization Previously, any arrays of values in a `multipart/form-data` body would be serialized as an `application/json` part. This matches the default behavior specified by OpenAPI and supports arrays of files (`binary` format strings). However, because this generator doesn't yet support specifying `encoding` per property, this may result in now-incorrect code when the encoding _was_ explicitly set to `application/json` for arrays of scalar values. PR #938 fixes #692. Thanks @micha91 for the fix, @ratgen and @FabianSchurig for testing, and @davidlizeng for the original report... many years ago 😅. Co-authored-by: knope-bot[bot] <152252888+knope-bot[bot]@users.noreply.github.com>
Describe the bug
For multipart/form-data with an array of files, generated code tries to serialize the array of files as JSON.
To Reproduce
Steps to reproduce the behavior:
openapi-python-client --path spec.json
The following error occurs:
Expected behavior
The generated code for handling an array of files seems to be trying to serialize the files as json:
Based on https://www.python-httpx.org/advanced/#multipart-file-encoding, we should probably be doing something more like the following, treating the multipart data as a list of tuples, with field keys that can repeat. Each file is added to the list under the same "files" key:
OpenAPI Spec File
Desktop (please complete the following information):
Additional context
Add any other context about the problem here.
The text was updated successfully, but these errors were encountered: