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

Discrepancy between encoding multipart/ examples and working with binary data sections #4293

Open
chrisradek opened this issue Jan 8, 2025 · 1 comment · May be fixed by #4294
Open

Discrepancy between encoding multipart/ examples and working with binary data sections #4293

chrisradek opened this issue Jan 8, 2025 · 1 comment · May be fixed by #4294
Assignees
Labels
Milestone

Comments

@chrisradek
Copy link

In the Open API 3.1.1 spec, there seems to be a discrepancy between how to represent binary data, and the examples around encoding multipart parts.

Working with binary data and migrating binary descriptions from OAS 3.0 indicate that type and format can be removed for raw binary data, and type with contentEncoding can be used (instead of format) for encoded binary data.

The multipart form with multiple files example follows this guidance, but the multipart form with encoding objects still specifies type and format for binary data.

The roughly same example in the Open API 3.1.0 spec uses an empty schema for raw binary data instead of format and type which is what I was expecting: https://spec.openapis.org/oas/v3.1.0.html#encoding-object-example

So I'm wondering if the change between 3.1.0 and 3.1.1 was intentional. Are there any scenarios where we should still be using format of byte or binary with OAS 3.1?

@handrews
Copy link
Member

handrews commented Jan 8, 2025

@chrisradek yikes, that's a copy-paste error from 3.0.4 (probably mine, I'm embarrassed to say). We'll get that fixed in 3.1.2 (there are some other errors we need to get fixed quickly as well).

@handrews handrews added this to the v3.1.2 milestone Jan 8, 2025
@handrews handrews added the bug label Jan 8, 2025
@handrews handrews self-assigned this Jan 9, 2025
@handrews handrews linked a pull request Jan 9, 2025 that will close this issue
@handrews handrews linked a pull request Jan 9, 2025 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants