Repository navigation
Create IPIP: UnixFS and Gateway support for explicit MIME/Content-Type #364
Description
Activity
- changed the title
[-]IPIP: UnixFS and Gateway support for explicit MIME/Content-Type[/-][+]Create IPIP: UnixFS and Gateway support for explicit MIME/Content-Type[/+]on Jan 12, 2023 Need some help with historical context:
- UnixFS 1.5 added
Data.modeandData.mtimefields- JS support landed a while ago (feat: adds metadata to unixfs js-ipfs-unixfs#36).
- GO support is in limbo, proposed in this PR
- What we propose in this issue is "UnixFS 1.6" (tbd)
- My initial idea was to add Content Type field as
Data.ctype.. - ... but I've noticed there is an existing
Metadata.MimeTypefield inunixfs.protoalready (seems to be not used for anything anywhere tho).
- My initial idea was to add Content Type field as
Feels like there is a reason why
Metadatawas not used formtimeandmode(see js-ipfs-unixfs/unixfs.proto)@achingbrain @alanshaw do you remember why these fields landed in
Dataand notMetadata? Or who would be good person to ask?- UnixFS 1.5 added
Some thoughts in case someone wants to pick this up in the future:
The UnixFS spec that merged in August 2025 has a legacy pb that already "reserves" a slot for this:
message Metadata { string MimeType = 1; }, andDataType Metadata = 3, both marked "reserved for future use". Nothing implements either.IIRC some of discussions we had, reusing that legacy
Metadatanode type is a trap. Implementations already disagree on howData_Metadatabehaves, which is why boxo returns early on it and points at #316. The shape with precedent is a new optional field onData, aftermode(7) andmtime(8), the same way UnixFS 1.5 added those.Whichever shape, it is opt-in and changes the CID of anything that sets it, and it only pays off once gateways act on it, which is the #257 side.
So the IPIP is still unwritten, but the design space is small now: choose the field, define precedence against extension sniffing and the existing default, and add gateway-conformance tests. Then implement it in both
boxo/gatewayand@helia/verified-fetch
This is a placeholder issue for creating IPIP to add support for storing explicit MIME/Content-Type in UnixFS DAG itself, like we already do for opt-in
modeandmtime, and acting on its presence on Gateways.There is alrernative approach to allow stating explicit content-type header via
_headersfile (similar to recently shipped_redirects) – some notes in #257Context
UnixFSv2 never happened, but ability to explicitly specify
Content-Typewas one of my asks: ipld/legacy-unixfs-v2#11Years later, we still guess
Content-Typeon gateways.While it is fine for most of the time, but we should provide users with ability to explicitly set media type at the time of data onboarding.
Since 2018 we made some related development: we've added opt-in support for
modeandmtimeattributes. ~2020 (#217 (comment)). Support formodeandmtimewas implemented in JS-IPFS a while ago, Kubo still has PR open (ipfs/go-unixfs#117).Initial idea (details to be fleshed out in IPIP) is to introduce optional
mtypesimilar way.This is alternative to introducing
_headersfile mentioned in #257.Ref.
Content-Type: Content Type set by HTTP Gateway in-web-browsers#152Content-Typebased on filename and magic bytes: https://github.com/ipfs/kubo/blob/v0.17.0-rc2/core/corehttp/gateway_handler_unixfs_file.go#L55-L87/ipfs/cidis requested without any filename, but with built-in support for explicit content type we could make it "just work".TODO
Content-Typeheader--content-typetoipfs addContent-Typeheader on gateway, if present