# IPFS Fetch

tk
- goal: develop a clear definition of [Fetch](https://fetch.spec.whatwg.org/) for IPFS,
to guarantee interoperability in browser implementations
- include some early notes about HTTP gateways
- perhaps include Verified HTTP Fetch: fetch that uses a trustless gateway, verifies, and
supports pathing locally
- include specification of the origin, which is anything reachable in the DAG (note that with
IPLD this could technically be the entire IPFS space)
- also specify caching and cache partitions
- It's tempting potentially to reuse blob fetching (which also supports ranging)
- top navigation and embedded resources should always do pathing, but script fetch could well
want to get a CAR. How do we enable that, knowing that this isn't an HTTP fetch? We should
*really* avoid using predefined query string parameters here. One option is that we could
use special request headers for that (perhaps reuse `Accept` even if the context isn't HTTP).
- From Fabrice: Some quick feedback about the implementation I did in gecko:- fetch() is very http tainted. In practice it's not that bad, since that helps with defining what's missing from UnixFS (content-type!!). I think it's fine to use the http semantics as much as possible for developers to be right at home. Caching is a mixed bag: on one hand, requests from gateways are served as immutable so they get pinned easily. On the other hand double keying prevents reuse when linking from other origins, which is annoying since fetching from ipfs is still on the slow side.
- https://github.com/ipfs/in-web-browsers/issues/207

## Addition to Scheme Fetch

tk
- this adds `ipfs` (and `ipns`, but we have to weigh origin and security implications) to
[scheme fetch](https://fetch.spec.whatwg.org/#concept-scheme-fetch) options.

## Open Questions

- Fetch supports a [local-URLs-only flag](https://fetch.spec.whatwg.org/#local-urls-only-flag),
how should it work with IFPS? A URL is [local](https://fetch.spec.whatwg.org/#is-local) if
its scheme is local, but that's not a meaningful distinction for content-addressed schemes.
The distinction also matters for
[Referrer Policy](https://w3c.github.io/webappsec-referrer-policy/#strip-url).
- How do we handle ranges (these aren't uncommon for instance with video or fonts)
- Do we want to support
[redirects](https://github.com/ipfs/specs/blob/main/http-gateways/REDIRECTS_FILE.md)? It
significantly increases the complexity of what we need to specify (eg. splat pathing and
the such).

## Misc
- A [JS implementation](https://github.com/RangerMauve/js-ipfs-fetch) from amazing Mauve