HTTP Path Gateway Specification
Path gateways are how a regular browser without IPFS support fetches content-addressed data. Knowing the spec is required to operate a self-hosted gateway, debug 404/range/CORS issues, or build clients that fall back from native IPFS to HTTP gateways.
What It Defines
Defines how an HTTP gateway exposes IPFS content under URL paths of the form `https://<gateway>/ipfs/<CID>/<path>` and `https://<gateway>/ipns/<name>/<path>`. Specifies request/response semantics: status codes, ETag/Cache-Control derived from CIDs, range requests, redirects, MIME-type sniffing, content disposition, and the `_redirects` / index.html handling that lets static sites work transparently. This is the gateway model that `ipfs.io`, `dweb.link`, and most public gateways implement, and it is what ordinary browsers actually talk to.
Canonical (Normative)
Convenient (Practical)
Open community of implementers (Protocol Labs, Shipyard, Boost, Helia, Kubo, and others) that maintains the InterPlanetary File System spec family at specs.ipfs.tech. Publishes content-addressing primitives (CID, Multihash, Multibase, Multiaddr), the IPLD data model, naming systems (IPNS, DNSLink), and the HTTP Gateway specs (Path, Subdomain, Trustless, DNSLink) that bridge content-addressed storage to ordinary browsers.
Related Specs
Every DNSLink record, IPFS gateway URL, IPNS publish, and Filecoin deal references content by CID. If you do not understand what the bytes after `/ipfs/` mean, you cannot debug deploy/cache issues, validate signed manifests, or design content-addressed pipelines.
If you do not want to update a DNS TXT record on every deploy, point DNSLink at IPNS and republish the IPNS record to the new CID. IPNS is the mutable pointer that makes content-addressed storage usable for evolving sites.
Path gateways break the web origin model — every CID shares the gateway origin. Subdomain gateways are the production-correct choice for hosting independent sites. This is also the only model that makes single-page apps with cookies and Service Workers function on a public gateway.
DNSLink alone tells nobody how a browser request actually turns into a served HTML page. The DNSLink Gateway spec is the contract between your DNS records and the gateway that browsers hit — required reading if you operate a custom gateway for user sites under a wildcard like `*.dial.wtf`.
This is the core contract of every web API, browser request, and server response. You can't design or debug HTTP without knowing this.
Correct caching is the difference between a fast app and an expensive, slow one. Mis-configured cache headers cause stale data bugs and unnecessary origin load.