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

oras attach single file layer mediaType could be inferred #1651

Open
1 task
polarathene opened this issue Mar 11, 2025 · 3 comments
Open
1 task

oras attach single file layer mediaType could be inferred #1651

polarathene opened this issue Mar 11, 2025 · 3 comments
Labels
enhancement New feature or request v2 features planned to deliver in 2.0.0

Comments

@polarathene
Copy link

What is the version of your ORAS CLI

1.2.2

What would you like to be added?

The oras attach docs do document how to set this with an explicit value, but given the hi.txt example, would it not make more sense to infer the MIME type when one is not provided?

$ xdg-mime query filetype hi.txt
text/plain

Results may vary by tool, but if this were inferred by the ORAS CLI it'd be more consistent?


I know another Golang project Caddy leverages Go stdlib mime package for this which as the link notes will expand support when the host provides /etc/mime.types. That doesn't infer MIME type by content, but by extension alone.

A snippet for reference is:

application/json                                json
application/json-patch+json                     json-patch
application/json-seq
application/jwk+json
application/jwk-set+json
application/jwt
application/ld+json                             jsonld

The 2nd column is the extension to map to a MIME type. Those without one are just added for completeness (thus no associated extension recognized).

Additional mappings can be added, the extension can be compound (this can be seen with both sarif.json and spdx.json), so for example adding in-toto attestation:

application/vnd.in-toto+json                   in-toto.json

For the most part though, it just seemed odd to default to assuming application/vnd.oci.image.layer.v1.tar? 😅

Why is this needed for ORAS?

It may not always be accurate but it should be more often than assuming application/vnd.oci.image.layer.v1.tar?

Uploading JSON for an in-toto attestation for example should be application/vnd.in-toto+json and that would need to be explicit.. but the default inference would still be a more accurate representation of the data:

# The extension isn't required:
$ xdg-mime query filetype attestation.json
application/json

Are you willing to submit PRs to contribute to this feature?

  • Yes, I am willing to implement it.
@polarathene polarathene added enhancement New feature or request triage New issues or PRs to be acknowledged by maintainers labels Mar 11, 2025
@Wwwsylvia
Copy link
Member

Hi @polarathene , we chose "application/vnd.oci.image.layer.v1.tar" as the default layer media type for compatibility reasons. Changing the default value would be considered a breaking change. We can look into a better value for the next major version. 🤔
/cc @shizhMSFT who may have something to add

@polarathene
Copy link
Author

Changing the default value would be considered a breaking change

It could be a opt-in change in the meantime if it's considered worthwhile.

It doesn't seem like there is any ENV or config file support with the tool documented, so I assume it'd only be via a CLI option?


We can look into a better value for the next major version

No worries 👍

Just a DX feedback that seemed worth suggesting when not explicitly setting the media type.

@shizhMSFT shizhMSFT added v2 features planned to deliver in 2.0.0 and removed triage New issues or PRs to be acknowledged by maintainers labels Mar 12, 2025
@Wwwsylvia
Copy link
Member

@polarathene The default value is defined in the underlying oras-go library (See https://github.com/oras-project/oras-go/blob/f3f718b3c423848c46b492669c7c433fb463b3fa/content/file/file.go#L56-L57).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request v2 features planned to deliver in 2.0.0
Projects
None yet
Development

No branches or pull requests

3 participants