feat: support redirects for UnixFS directories #5
Conversation
Adds support for simulating redirects for UnixFS directories.
We're somewhat in uncharted water here because window.fetch does this
transparently unless you specify a `redirect` option, none of which
actually allow you to follow a redirect.
The states we can be in are:
1. URL: `ipfs://QmFoo/dir/`
- Happy path
- 200 response
- `response.redirected = false`
- `response.url = 'ipfs://QmFoo/dir'`
2: URL: `ipfs://QmFoo/dir`, `redirect: 'follow'`
- The default value
- Simulates automatically following a redirect
- 200 response
- `response.redirected = true`
- `response.url = 'ipfs://QmFoo/dir/'`
3: URL: `ipfs://QmFoo/dir`, `redirect: 'error'`
- Return an error if a redirect would take place
- Throws `TypeError('Failed to Fetch')` same as `window.fetch`
4: URL: `ipfs://QmFoo/dir`, `redirect: 'manual'`
- Allows a caller to take action on the redirect
- 301 response
- `response.redirected = false`
- `response.url = 'ipfs://QmFoo/dir`
- `response.headers.get('location') = 'ipfs://QmFoo/dir/'`
Number 4 is the furthest from [the fetch spec](https://fetch.spec.whatwg.org/#concept-request-redirect-mode)
but to follow the spec would make it impossible to actually follow a
redirect.
There was a problem hiding this comment.
Thank you for wiring this up!
Option 4 sounds like a sensible compromise to implement fix for ipfs/service-worker-gateway#62, and will make things even easier in future when we accept HTTP URLs as-is.
The { redirect: 'manual' } is a very niche feature, and the fact we don't have opaque response (or any other divergence from regular fetch) should not have negative impact real world users.
The "spirit" of https://fetch.spec.whatwg.org/#atomic-http-redirect-handling is to not leak cross-origin information not otherwise available, and we don't introduce any new info in location header or body (anyone can grab CID from URL and learn it is a directory themselves).
## @helia/verified-fetch [1.1.0](https://github.com/ipfs/helia-verified-fetch/compare/@helia/verified-fetch-1.0.2...@helia/verified-fetch-1.1.0) (2024-03-03) ### Features * support IPFS/IPNS paths, Gateways, etc ([#4](#4)) ([e7f1816](e7f1816)) * support redirects for UnixFS directories ([#5](#5)) ([4601d46](4601d46)) ### Trivial Changes * unskip IPNS test ([#6](#6)) ([76485a4](76485a4))
|
🎉 This PR is included in version 1.1.0 🎉 The release is available on npm package (@latest dist-tag) Your semantic-release bot 📦🚀 |
|
🎉 This PR is included in version 1.3.0 🎉 The release is available on npm package (@latest dist-tag) Your semantic-release bot 📦🚀 |
This ensures fix introduced in ipfs/helia-verified-fetch#5 is returned to the browser, instead of following it and returning final bytes.
|
🎉 This PR is included in version 1.0.0 🎉 The release is available on npm package (@latest dist-tag) Your semantic-release bot 📦🚀 |
Adds support for simulating redirects for UnixFS directories.
We're somewhat in uncharted water here because
window.fetchdoes this transparently unless you specify a redirect option, none of which actually allow you to manually follow a redirect.The states we can be in are:
ipfs://QmFoo/dir/response.redirected = falseresponse.url = 'ipfs://QmFoo/dir'2: URL:
ipfs://QmFoo/dir,redirect: 'follow'response.redirected = trueresponse.url = 'ipfs://QmFoo/dir/'3: URL:
ipfs://QmFoo/dir,redirect: 'error'TypeError('Failed to Fetch')same aswindow.fetch4: URL:
ipfs://QmFoo/dir,redirect: 'manual'response.redirected = falseresponse.url = 'ipfs://QmFoo/dirresponse.headers.get('location') = 'ipfs://QmFoo/dir/'Number 4 is the furthest from the fetch spec but to follow the spec would make it impossible to actually follow a redirect.
Refs: ipfs/service-worker-gateway#62
Change checklist