Created by: rienafairefr
PR checklist
-
Read the contribution guidelines. -
Ran the shell script under ./bin/
to update Petstore sample so that CIs can verify the change. (For instance, only need to run./bin/{LANG}-petstore.sh
,./bin/openapi3/{LANG}-petstore.sh
,./bin/security/{LANG}-petstore.sh
and./bin/openapi3/security/{LANG}-petstore.sh
if updating the {LANG} (e.g. php, ruby, python, etc) code generator or {LANG} client's mustache templates). Windows batch files can be found in.\bin\windows\
. -
Filed the PR against the correct branch: master
,. Default:3.4.x
,4.0.x
master
. -
Copied the technical committee to review the pull request if your PR is targeting a particular programming language. @wing328 @kenjones-cisco @tomplus @Jyhess
Description of the PR
as described in #2165 (closed), the client doesnt handle well sending mixed-type multipart.
This PR adds support for the OAS3 encoding
field that can be found in the requestbody in the case of a multipart type:
spect here, which is used to described the content type and headers of each multipart part (sic).
There is a possibility of multipart header parameters, because each multipart field can be added a headers
property that can be varied by the caller, so I've added a multipartHeaderParams
field that can be used for that.
I've implemented all this logic in the Python client. In the case of a multipart
operation, instead of post_params
being a list of simple (name, value)
tuples, we can make complex cases by using urllib3 RequestField
directly
field = RequestField(name, value, headers=headers)
field.make_multipart(headers.get('Content-Disposition'),
content_type,
headers.get('Content-Location'))
I don't have an API that necessitates the variable header thing, but the mixed Content-Type
are working fine. When using parameters that are file
, there still a bug the files are uploaded as string like
<filename>,b'<binary-data>'
, but it's related to previously reported issue #2118 (closed)