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

Question: Content-Encoding HTTP header field and contentEncoding #2476

Closed
ioggstream opened this issue Feb 18, 2021 · 7 comments · Fixed by #3727
Closed

Question: Content-Encoding HTTP header field and contentEncoding #2476

ioggstream opened this issue Feb 18, 2021 · 7 comments · Fixed by #3727
Assignees
Labels
clarification requests to clarify, but not change, part of the spec media and encoding Issues regarding media type support and how to encode data (outside of query/path params)
Milestone

Comments

@ioggstream
Copy link
Contributor

Question

Reading the following part https://github.com/OAI/OpenAPI-Specification/blame/master/versions/3.1.0.md#L1451
it is not clear to me the meaning of the following sentence

contentEncoding keyword [..] may be used to specify the Content-Encoding for the schema.

My understanding is that it specifies the encoding used to serialize the application data before it is passed
to the HTTP layer, which eventually adds one or more content-codings.

The encoding specified by the contentEncoding keyword
is independent of an encoding specified by the Content-Type header
in the request or response or metadata of a multipart body
[..] then the encoding specified in the Content-Type header.

Is Content-Type the HTTP header field? In that case, iiuc its value is a media-type: how can I specify an encoding? Does it mean "charset"?

cc: @handrews

@handrews
Copy link
Member

Hmm... maybe that was supposed to be Content-Encoding? The encodings in Content-Encoding are things like gzip (compression applied at the HTTP layer) while the encodings in contentEncoding are application-level things like base64, base64url, or quoted-printable.

@ioggstream
Copy link
Contributor Author

Content-Encoding should work, as it contains an ordered list of content-codings. I can make a PR but dunno if we should align json-schema too.

Probably some more explanation are required because if I contentEncoding eg. a jpeg in base64 my understanding is that it's probably no more an HTTP Content-Type: image/jpg but something else. In general, I finf the name contentEncoding bearing a lot of possible different meanings in the HTTP context (again, it's jsonschema stuff probably).

WDYT?

@handrews
Copy link
Member

@ioggstream JSON Schema's contentEncoding is correct as it is. I think the only error is that I (or someone) typed Content-Type instead of Content-Encoding.

@ioggstream
Copy link
Contributor Author

@ioggstream JSON Schema's contentEncoding is correct as it is. I think the only error is that I (or someone) typed Content-Type instead of Content-Encoding.

What I don't get is

contentEncoding keyword [..] may be used to specify the Content-Encoding for the schema

json-schema has a Content-Encoding ?

ioggstream added a commit to ioggstream/OpenAPI-Specification that referenced this issue Feb 18, 2021
This PR distinguish between Content-Encoding HTTP header field, which is an ordered list of content-codings
 and Content-Transfer-Encoding which is a multipart header (see https://tools.ietf.org/html/rfc7578#section-4.5).
@handrews
Copy link
Member

@ioggstream JSON Schema's contentEncoding keyword does something different from HTTP's Content-Encoding header. This happens when different standards have different backgrounds and there are only so many words to use. JSON Schema's contentEncoding uses encodings from RFC 4648 (and to a lesser degree, RFC 2045. These come from MIME's Content-Transfer-Encoding header, which (again) is not the same as HTTP's Content-Encoding header. But JSON Schema doesn't do transferring. Anyway, HTTP notes this issue (MIME vs HTTP headers) in RFC 7231 as well.

@ioggstream
Copy link
Contributor Author

@handrews sure! Please check the attached PR which should clarify a bit.

@handrews handrews added clarification requests to clarify, but not change, part of the spec media and encoding Issues regarding media type support and how to encode data (outside of query/path params) labels Jan 28, 2024
@handrews handrews self-assigned this Apr 20, 2024
@handrews handrews linked a pull request Apr 20, 2024 that will close this issue
@handrews
Copy link
Member

PRs merged for 3.1.1 and 3.2.0 - closing!

@handrews handrews added this to the v3.1.1 milestone May 22, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
clarification requests to clarify, but not change, part of the spec media and encoding Issues regarding media type support and how to encode data (outside of query/path params)
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants