Support multiple contentTypes in encoding multipart/form-data
Question
Hi !
I have tried to upload an image that can be either a png or a jpeg, but It didn't work for me.
Here's a demo of a requestBody that I used to achieve the following according to OpenAPI encoding specification:
requestBody:
description: The avatar file
required: true
content:
multipart/form-data:
schema:
type: object
properties:
file:
type: string
encoding:
file:
contentType: image/png, image/jpeg
Unfortunatly, I'm getting this error:
Validation warning: Inconsistency encountered when parsing ``: 'image/png, image/jpeg' could not be parsed as a Content Type. Content Types should have the format '<type>/<subtype>'. [context: codingPath=.paths['/profiles/{id}/avatar'].post.requestBody.content['multipart/form-data'].encoding.file.contentType, contextString=, subjectName=]warning: Validation warning: Inconsistency encountered when parsing ``: 'image/png, image/jpeg' could not be parsed as a Content Type. Content Types should have the format '<type>/<subtype>'. [context: codingPath=.paths['/profiles/{id}/avatar'].post.requestBody.content['multipart/form-data'].encoding.file.contentType, contextString=, subjectName=]Error: Invalid content type string: 'image/png, image/jpeg', must have 2 components separated by a slash.
Can you tell me what I did wrong ?
Thanks !
It seems that we (through using OpenAPIKit) don't currently support a list of contentType, please try again by removing the second content type and just keep one.
cc @mattpolzin If I'm reading this right, this should be valid: https://github.com/OAI/OpenAPI-Specification/blob/main/versions/3.1.0.md#encoding-object
Yeah, a comma separated string is indeed valid there according to the spec. I just created a bug ticket to track this here.
Hi,
Thanks for your prompt response. Noted, I'll be following till It's fixed ;)
This has been fixed upstream as of OpenAPIKit 3.2.0. Parsing should be fixed just by updating; actually using multiple content types will require using the new OpenAPIKit.Content.Encoding property contentTypes.
~The next alpha release of OpenAPIKit 4.0.0 (in the works right now) will also contain the fix~ OpenAPIKit 4.0.0-alpha.6 also contains the fix.
@mbachircherif would you confirm this resolved your issue by running swift package update?
Thanks @mattpolzin! 🙏
Or, I haven't actually checked (just doing drive by here). we might need to update the generator. In which case we'll do that soon.
@simonjbeaumont I confirm, no more issues after update. Thanks all for your work !
The OpenAPIKit fix should unblock parsing of the OpenAPI doc, and will mostly make this work. But not fully, because I suspect this way we only send the first content type, instead of allowing the adopter to choose from the list.
If we can confirm that's the case, we can use this issue to track adding fuller support.
The support in OpenAPIKit landed, for anyone interested in contributing the enhancement, you should be unblocked.