Storing Explicit Content Type

[lidel]

For some reason I was under impression unixfs-v2 has an option to set explicit content-type (aka mime/media-type) that travels along with data, but I did not found any discussion (cc #1 #10) about it.

My working assumption is that one could store it as one of optional "Extended Attributes", as noted in #2.

Is this assumption correct?
If not, what is the current line of thought when it comes to media types and IPFS?

Digression On Ambiguous Bytes

Depending on assumed content-type, the meaning and presentation of specific types of data may change drastically, breaking UX assumption made by the original author.

There are other examples floating around, but a poster child for storing explicit content-type for some types of content is SVG (image/svg+xml).
It produced issues every now and then by being mime-sniffed incorrectly:

• Gateway content-type response header ipfs-inactive/faq#224 (comment) (2017)
• fix: fix content-type by doing a fall-back using extensions ipfs/js-ipfs-http-response#5 (last week)
• fix: fix content-type detection by doing a fall-back based on the ext… ipfs/js-ipfs#1482 (last week)

I am working on custom protocol handler in web browsers, and noticed edge cases where it would be really beneficial to have an option to provide own media type with media itself and avoid media type sniffing, be it userland javascript or the browser itself. Same goes for HTTP gateway in go-ipfs: it could take advantage of additional media type metadata (if present) and set proper Content-Type header without relying on net/http/sniff.go. There are security contexts in which it makes sense to set X-Content-Type-Options: nosniff and AFAIK right now we don't have any good answer for that. Supporting media type as optional value in unixfs-v2 could be a viable one.

[Stebalien]

Yes. The idea is that users would be able to add arbitrary custom attributes/metadata (even custom links to other objects).

[rvagg]

closing for archival