@helia/verified-fetch 0.0.0-5c0c39c → 0.0.0-6f8c15b
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/README.md +313 -44
- package/dist/index.min.js +7 -29
- package/dist/src/index.d.ts +369 -54
- package/dist/src/index.d.ts.map +1 -1
- package/dist/src/index.js +326 -49
- package/dist/src/index.js.map +1 -1
- package/dist/src/singleton.d.ts +3 -0
- package/dist/src/singleton.d.ts.map +1 -0
- package/dist/src/singleton.js +15 -0
- package/dist/src/singleton.js.map +1 -0
- package/dist/src/types.d.ts +2 -0
- package/dist/src/types.d.ts.map +1 -0
- package/dist/src/types.js +2 -0
- package/dist/src/types.js.map +1 -0
- package/dist/src/utils/dag-cbor-to-safe-json.d.ts +7 -0
- package/dist/src/utils/dag-cbor-to-safe-json.d.ts.map +1 -0
- package/dist/src/utils/dag-cbor-to-safe-json.js +37 -0
- package/dist/src/utils/dag-cbor-to-safe-json.js.map +1 -0
- package/dist/src/utils/get-content-disposition-filename.d.ts +6 -0
- package/dist/src/utils/get-content-disposition-filename.d.ts.map +1 -0
- package/dist/src/utils/get-content-disposition-filename.js +16 -0
- package/dist/src/utils/get-content-disposition-filename.js.map +1 -0
- package/dist/src/utils/get-e-tag.d.ts +28 -0
- package/dist/src/utils/get-e-tag.d.ts.map +1 -0
- package/dist/src/utils/get-e-tag.js +18 -0
- package/dist/src/utils/get-e-tag.js.map +1 -0
- package/dist/src/utils/get-stream-from-async-iterable.d.ts +10 -0
- package/dist/src/utils/get-stream-from-async-iterable.d.ts.map +1 -0
- package/dist/src/utils/{get-stream-and-content-type.js → get-stream-from-async-iterable.js} +10 -9
- package/dist/src/utils/get-stream-from-async-iterable.js.map +1 -0
- package/dist/src/utils/get-tar-stream.d.ts +4 -0
- package/dist/src/utils/get-tar-stream.d.ts.map +1 -0
- package/dist/src/utils/get-tar-stream.js +46 -0
- package/dist/src/utils/get-tar-stream.js.map +1 -0
- package/dist/src/utils/parse-url-string.d.ts +7 -1
- package/dist/src/utils/parse-url-string.d.ts.map +1 -1
- package/dist/src/utils/parse-url-string.js +6 -0
- package/dist/src/utils/parse-url-string.js.map +1 -1
- package/dist/src/utils/responses.d.ts +5 -0
- package/dist/src/utils/responses.d.ts.map +1 -0
- package/dist/src/utils/responses.js +27 -0
- package/dist/src/utils/responses.js.map +1 -0
- package/dist/src/utils/select-output-type.d.ts +12 -0
- package/dist/src/utils/select-output-type.d.ts.map +1 -0
- package/dist/src/utils/select-output-type.js +148 -0
- package/dist/src/utils/select-output-type.js.map +1 -0
- package/dist/src/verified-fetch.d.ts +23 -27
- package/dist/src/verified-fetch.d.ts.map +1 -1
- package/dist/src/verified-fetch.js +288 -141
- package/dist/src/verified-fetch.js.map +1 -1
- package/package.json +40 -18
- package/src/index.ts +377 -55
- package/src/singleton.ts +20 -0
- package/src/types.ts +1 -0
- package/src/utils/dag-cbor-to-safe-json.ts +44 -0
- package/src/utils/get-content-disposition-filename.ts +18 -0
- package/src/utils/get-e-tag.ts +36 -0
- package/src/utils/{get-stream-and-content-type.ts → get-stream-from-async-iterable.ts} +9 -8
- package/src/utils/get-tar-stream.ts +68 -0
- package/src/utils/parse-url-string.ts +17 -2
- package/src/utils/responses.ts +29 -0
- package/src/utils/select-output-type.ts +167 -0
- package/src/verified-fetch.ts +340 -153
- package/dist/src/utils/get-content-type.d.ts +0 -11
- package/dist/src/utils/get-content-type.d.ts.map +0 -1
- package/dist/src/utils/get-content-type.js +0 -43
- package/dist/src/utils/get-content-type.js.map +0 -1
- package/dist/src/utils/get-stream-and-content-type.d.ts +0 -10
- package/dist/src/utils/get-stream-and-content-type.d.ts.map +0 -1
- package/dist/src/utils/get-stream-and-content-type.js.map +0 -1
- package/src/utils/get-content-type.ts +0 -55
package/README.md
CHANGED
|
@@ -13,28 +13,43 @@
|
|
|
13
13
|
|
|
14
14
|
# About
|
|
15
15
|
|
|
16
|
-
|
|
16
|
+
<!--
|
|
17
17
|
|
|
18
|
-
|
|
18
|
+
!IMPORTANT!
|
|
19
19
|
|
|
20
|
-
|
|
20
|
+
Everything in this README between "# About" and "# Install" is automatically
|
|
21
|
+
generated and will be overwritten the next time the doc generator is run.
|
|
22
|
+
|
|
23
|
+
To make changes to this section, please update the @packageDocumentation section
|
|
24
|
+
of src/index.js or src/index.ts
|
|
25
|
+
|
|
26
|
+
To experiment with formatting, please run "npm run docs" from the root of this
|
|
27
|
+
repo and examine the changes made.
|
|
28
|
+
|
|
29
|
+
-->
|
|
30
|
+
|
|
31
|
+
`@helia/verified-fetch` provides a [fetch](https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API)-like API for retrieving content from the [IPFS](https://ipfs.tech/) network.
|
|
32
|
+
|
|
33
|
+
All content is retrieved in a [trustless manner](https://www.techopedia.com/definition/trustless), and the integrity of all bytes are verified by comparing hashes of the data. By default, CIDs are retrieved over HTTP from [trustless gateways](https://specs.ipfs.tech/http-gateways/trustless-gateway/).
|
|
34
|
+
|
|
35
|
+
This is a marked improvement over `fetch` which offers no such protections and is vulnerable to all sorts of attacks like [Content Spoofing](https://owasp.org/www-community/attacks/Content_Spoofing), [DNS Hijacking](https://en.wikipedia.org/wiki/DNS_hijacking), etc.
|
|
36
|
+
|
|
37
|
+
A `verifiedFetch` function is exported to get up and running quickly, and a `createVerifiedFetch` function is also available that allows customizing the underlying [Helia](https://helia.io/) node for complete control over how content is retrieved.
|
|
38
|
+
|
|
39
|
+
Browser-cache-friendly [Response](https://developer.mozilla.org/en-US/docs/Web/API/Response) objects are returned which should be instantly familiar to web developers.
|
|
21
40
|
|
|
22
41
|
You may use any supported resource argument to fetch content:
|
|
23
42
|
|
|
24
|
-
- CID instance
|
|
43
|
+
- [CID](https://multiformats.github.io/js-multiformats/classes/cid.CID.html) instance
|
|
25
44
|
- IPFS URL
|
|
26
45
|
- IPNS URL
|
|
27
46
|
|
|
28
|
-
## Example
|
|
47
|
+
## Example - Getting started
|
|
29
48
|
|
|
30
49
|
```typescript
|
|
31
|
-
import {
|
|
50
|
+
import { verifiedFetch } from '@helia/verified-fetch'
|
|
32
51
|
|
|
33
|
-
const
|
|
34
|
-
gateways: ['https://mygateway.example.net', 'https://trustless-gateway.link']
|
|
35
|
-
})
|
|
36
|
-
|
|
37
|
-
const resp = await fetch('ipfs://bafy...')
|
|
52
|
+
const resp = await verifiedFetch('ipfs://bafy...')
|
|
38
53
|
|
|
39
54
|
const json = await resp.json()
|
|
40
55
|
```
|
|
@@ -42,27 +57,20 @@ const json = await resp.json()
|
|
|
42
57
|
## Example - Using a CID instance to fetch JSON
|
|
43
58
|
|
|
44
59
|
```typescript
|
|
45
|
-
import {
|
|
60
|
+
import { verifiedFetch } from '@helia/verified-fetch'
|
|
46
61
|
import { CID } from 'multiformats/cid'
|
|
47
62
|
|
|
48
|
-
const
|
|
49
|
-
|
|
50
|
-
})
|
|
51
|
-
|
|
52
|
-
const cid = CID.parse('bafyFoo') // some image file
|
|
53
|
-
const response = await fetch(cid)
|
|
63
|
+
const cid = CID.parse('bafyFoo') // some json file
|
|
64
|
+
const response = await verifiedFetch(cid)
|
|
54
65
|
const json = await response.json()
|
|
55
66
|
```
|
|
56
67
|
|
|
57
68
|
## Example - Using IPFS protocol to fetch an image
|
|
58
69
|
|
|
59
70
|
```typescript
|
|
60
|
-
import {
|
|
71
|
+
import { verifiedFetch } from '@helia/verified-fetch'
|
|
61
72
|
|
|
62
|
-
const
|
|
63
|
-
gateways: ['https://mygateway.example.net', 'https://trustless-gateway.link']
|
|
64
|
-
})
|
|
65
|
-
const response = await fetch('ipfs://bafyFoo') // CID for some image file
|
|
73
|
+
const response = await verifiedFetch('ipfs://bafyFoo') // CID for some image file
|
|
66
74
|
const blob = await response.blob()
|
|
67
75
|
const image = document.createElement('img')
|
|
68
76
|
image.src = URL.createObjectURL(blob)
|
|
@@ -71,23 +79,43 @@ document.body.appendChild(image)
|
|
|
71
79
|
|
|
72
80
|
## Example - Using IPNS protocol to stream a big file
|
|
73
81
|
|
|
82
|
+
```typescript
|
|
83
|
+
import { verifiedFetch } from '@helia/verified-fetch'
|
|
84
|
+
|
|
85
|
+
const response = await verifiedFetch('ipns://mydomain.com/path/to/very-long-file.log')
|
|
86
|
+
const bigFileStreamReader = await response.body.getReader()
|
|
87
|
+
```
|
|
88
|
+
|
|
89
|
+
## Configuration
|
|
90
|
+
|
|
91
|
+
### Custom HTTP gateways and routers
|
|
92
|
+
|
|
93
|
+
Out of the box `@helia/verified-fetch` uses a default set of [trustless gateways](https://specs.ipfs.tech/http-gateways/trustless-gateway/) for fetching blocks and [HTTP delegated routers](https://specs.ipfs.tech/routing/http-routing-v1/) for performing routing tasks - looking up peers, resolving/publishing [IPNS](https://docs.ipfs.tech/concepts/ipns/) names, etc.
|
|
94
|
+
|
|
95
|
+
It's possible to override these by passing `gateways` and `routers` keys to the `createVerifiedFetch` function:
|
|
96
|
+
|
|
97
|
+
## Example - Configuring gateways and routers
|
|
98
|
+
|
|
74
99
|
```typescript
|
|
75
100
|
import { createVerifiedFetch } from '@helia/verified-fetch'
|
|
76
101
|
|
|
77
102
|
const fetch = await createVerifiedFetch({
|
|
78
|
-
gateways: ['https://
|
|
103
|
+
gateways: ['https://trustless-gateway.link'],
|
|
104
|
+
routers: ['http://delegated-ipfs.dev']
|
|
79
105
|
})
|
|
80
|
-
|
|
81
|
-
const
|
|
106
|
+
|
|
107
|
+
const resp = await fetch('ipfs://bafy...')
|
|
108
|
+
|
|
109
|
+
const json = await resp.json()
|
|
82
110
|
```
|
|
83
111
|
|
|
84
|
-
###
|
|
112
|
+
### Usage with customized Helia
|
|
85
113
|
|
|
86
|
-
|
|
114
|
+
For full control of how `@helia/verified-fetch` fetches content from the distributed web you can pass a preconfigured Helia node to `createVerifiedFetch`.
|
|
87
115
|
|
|
88
|
-
|
|
116
|
+
The [helia](https://www.npmjs.com/package/helia) module is configured with a libp2p node that is suited for decentralized applications, alternatively [@helia/http](https://www.npmjs.com/package/@helia/http) is available which uses HTTP gateways for all network operations.
|
|
89
117
|
|
|
90
|
-
|
|
118
|
+
You can see variations of Helia and js-libp2p configuration options at <https://helia.io/interfaces/helia.index.HeliaInit.html>.
|
|
91
119
|
|
|
92
120
|
```typescript
|
|
93
121
|
import { trustlessGateway } from '@helia/block-brokers'
|
|
@@ -111,28 +139,269 @@ const resp = await fetch('ipfs://bafy...')
|
|
|
111
139
|
const json = await resp.json()
|
|
112
140
|
```
|
|
113
141
|
|
|
114
|
-
###
|
|
142
|
+
### Custom content-type parsing
|
|
143
|
+
|
|
144
|
+
By default, if the response can be parsed as JSON, `@helia/verified-fetch` sets the `Content-Type` header as `application/json`, otherwise it sets it as `application/octet-stream` - this is because the `.json()`, `.text()`, `.blob()`, and `.arrayBuffer()` methods will usually work as expected without a detailed content type.
|
|
145
|
+
|
|
146
|
+
If you require an accurate content-type you can provide a `contentTypeParser` function as an option to `createVerifiedFetch` to handle parsing the content type.
|
|
147
|
+
|
|
148
|
+
The function you provide will be called with the first chunk of bytes from the file and should return a string or a promise of a string.
|
|
149
|
+
|
|
150
|
+
## Example - Customizing content-type parsing
|
|
151
|
+
|
|
152
|
+
```typescript
|
|
153
|
+
import { createVerifiedFetch } from '@helia/verified-fetch'
|
|
154
|
+
import { fileTypeFromBuffer } from '@sgtpooki/file-type'
|
|
155
|
+
|
|
156
|
+
const fetch = await createVerifiedFetch({
|
|
157
|
+
gateways: ['https://trustless-gateway.link'],
|
|
158
|
+
routers: ['http://delegated-ipfs.dev']
|
|
159
|
+
}, {
|
|
160
|
+
contentTypeParser: async (bytes) => {
|
|
161
|
+
// call to some magic-byte recognition library like magic-bytes, file-type, or your own custom byte recognition
|
|
162
|
+
const result = await fileTypeFromBuffer(bytes)
|
|
163
|
+
return result?.mime
|
|
164
|
+
}
|
|
165
|
+
})
|
|
166
|
+
```
|
|
167
|
+
|
|
168
|
+
### IPLD codec handling
|
|
169
|
+
|
|
170
|
+
IPFS supports several data formats (typically referred to as codecs) which are included in the CID. `@helia/verified-fetch` attempts to abstract away some of the details for easier consumption.
|
|
171
|
+
|
|
172
|
+
#### DAG-PB
|
|
173
|
+
|
|
174
|
+
[DAG-PB](https://ipld.io/docs/codecs/known/dag-pb/) is the codec we are most likely to encounter, it is what [UnixFS](https://github.com/ipfs/specs/blob/main/UNIXFS.md) uses under the hood.
|
|
175
|
+
|
|
176
|
+
##### Using the DAG-PB codec as a Blob
|
|
177
|
+
|
|
178
|
+
```typescript
|
|
179
|
+
import { verifiedFetch } from '@helia/verified-fetch'
|
|
180
|
+
|
|
181
|
+
const res = await verifiedFetch('ipfs://Qmfoo')
|
|
182
|
+
const blob = await res.blob()
|
|
183
|
+
|
|
184
|
+
console.info(blob) // Blob { size: x, type: 'application/octet-stream' }
|
|
185
|
+
```
|
|
186
|
+
|
|
187
|
+
##### Using the DAG-PB codec as an ArrayBuffer
|
|
188
|
+
|
|
189
|
+
```typescript
|
|
190
|
+
import { verifiedFetch } from '@helia/verified-fetch'
|
|
191
|
+
|
|
192
|
+
const res = await verifiedFetch('ipfs://Qmfoo')
|
|
193
|
+
const buf = await res.arrayBuffer()
|
|
194
|
+
|
|
195
|
+
console.info(buf) // ArrayBuffer { [Uint8Contents]: < ... >, byteLength: x }
|
|
196
|
+
```
|
|
197
|
+
|
|
198
|
+
##### Using the DAG-PB codec as a stream
|
|
199
|
+
|
|
200
|
+
```typescript
|
|
201
|
+
import { verifiedFetch } from '@helia/verified-fetch'
|
|
202
|
+
|
|
203
|
+
const res = await verifiedFetch('ipfs://Qmfoo')
|
|
204
|
+
const reader = res.body?.getReader()
|
|
205
|
+
|
|
206
|
+
while (true) {
|
|
207
|
+
const next = await reader.read()
|
|
208
|
+
|
|
209
|
+
if (next?.done === true) {
|
|
210
|
+
break
|
|
211
|
+
}
|
|
212
|
+
|
|
213
|
+
if (next?.value != null) {
|
|
214
|
+
console.info(next.value) // Uint8Array(x) [ ... ]
|
|
215
|
+
}
|
|
216
|
+
}
|
|
217
|
+
```
|
|
218
|
+
|
|
219
|
+
##### Content-Type
|
|
220
|
+
|
|
221
|
+
When fetching `DAG-PB` data, the content type will be set to `application/octet-stream` unless a custom content-type parser is configured.
|
|
222
|
+
|
|
223
|
+
#### JSON
|
|
224
|
+
|
|
225
|
+
The JSON codec is a very simple codec, a block parseable with this codec is a JSON string encoded into a `Uint8Array`.
|
|
226
|
+
|
|
227
|
+
##### Using the JSON codec
|
|
228
|
+
|
|
229
|
+
```typescript
|
|
230
|
+
import * as json from 'multiformats/codecs/json'
|
|
231
|
+
|
|
232
|
+
const block = new TextEncoder().encode('{ "hello": "world" }')
|
|
233
|
+
const obj = json.decode(block)
|
|
234
|
+
|
|
235
|
+
console.info(obj) // { hello: 'world' }
|
|
236
|
+
```
|
|
237
|
+
|
|
238
|
+
##### Content-Type
|
|
239
|
+
|
|
240
|
+
When the `JSON` codec is encountered, the `Content-Type` header of the response will be set to `application/json`.
|
|
241
|
+
|
|
242
|
+
### DAG-JSON
|
|
243
|
+
|
|
244
|
+
[DAG-JSON](https://ipld.io/docs/codecs/known/dag-json/) expands on the `JSON` codec, adding the ability to contain [CID](https://docs.ipfs.tech/concepts/content-addressing/)s which act as links to other blocks, and byte arrays.
|
|
245
|
+
|
|
246
|
+
`CID`s and byte arrays are represented using special object structures with a single `"/"` property.
|
|
247
|
+
|
|
248
|
+
Using `DAG-JSON` has two important caveats:
|
|
249
|
+
|
|
250
|
+
1. Your `JSON` structure cannot contain an object with only a `"/"` property, as it will be interpreted as a special type.
|
|
251
|
+
2. Since `JSON` has no technical limit on number sizes, `DAG-JSON` also allows numbers larger than `Number.MAX_SAFE_INTEGER`. JavaScript requires use of `BigInt`s to represent numbers larger than this, and `JSON.parse` does not support them, so precision will be lost.
|
|
252
|
+
|
|
253
|
+
Otherwise this codec follows the same rules as the `JSON` codec.
|
|
254
|
+
|
|
255
|
+
##### Using the DAG-JSON codec
|
|
256
|
+
|
|
257
|
+
```typescript
|
|
258
|
+
import * as dagJson from '@ipld/dag-json'
|
|
259
|
+
|
|
260
|
+
const block = new TextEncoder().encode(`{
|
|
261
|
+
"hello": "world",
|
|
262
|
+
"cid": {
|
|
263
|
+
"/": "baeaaac3imvwgy3zao5xxe3de"
|
|
264
|
+
},
|
|
265
|
+
"buf": {
|
|
266
|
+
"/": {
|
|
267
|
+
"bytes": "AAECAwQ"
|
|
268
|
+
}
|
|
269
|
+
}
|
|
270
|
+
}`)
|
|
271
|
+
|
|
272
|
+
const obj = dagJson.decode(block)
|
|
273
|
+
|
|
274
|
+
console.info(obj)
|
|
275
|
+
// {
|
|
276
|
+
// hello: 'world',
|
|
277
|
+
// cid: CID(baeaaac3imvwgy3zao5xxe3de),
|
|
278
|
+
// buf: Uint8Array(5) [ 0, 1, 2, 3, 4 ]
|
|
279
|
+
// }
|
|
280
|
+
```
|
|
281
|
+
|
|
282
|
+
##### Content-Type
|
|
283
|
+
|
|
284
|
+
When the `DAG-JSON` codec is encountered in the requested CID, the `Content-Type` header of the response will be set to `application/json`.
|
|
285
|
+
|
|
286
|
+
`DAG-JSON` data can be parsed from the response by using the `.json()` function, which will return `CID`s/byte arrays as plain `{ "/": ... }` objects:
|
|
287
|
+
|
|
288
|
+
```typescript
|
|
289
|
+
import { verifiedFetch } from '@helia/verified-fetch'
|
|
290
|
+
import * as dagJson from '@ipld/dag-json'
|
|
291
|
+
|
|
292
|
+
const res = await verifiedFetch('ipfs://bafyDAGJSON')
|
|
293
|
+
|
|
294
|
+
// either:
|
|
295
|
+
const obj = await res.json()
|
|
296
|
+
console.info(obj.cid) // { "/": "baeaaac3imvwgy3zao5xxe3de" }
|
|
297
|
+
console.info(obj.buf) // { "/": { "bytes": "AAECAwQ" } }
|
|
298
|
+
```
|
|
299
|
+
|
|
300
|
+
Alternatively, it can be decoded using the `@ipld/dag-json` module and the `.arrayBuffer()` method, in which case you will get `CID` objects and `Uint8Array`s:
|
|
301
|
+
|
|
302
|
+
```typescript
|
|
303
|
+
import { verifiedFetch } from '@helia/verified-fetch'
|
|
304
|
+
import * as dagJson from '@ipld/dag-json'
|
|
305
|
+
|
|
306
|
+
const res = await verifiedFetch('ipfs://bafyDAGJSON')
|
|
307
|
+
|
|
308
|
+
// or:
|
|
309
|
+
const obj = dagJson.decode(await res.arrayBuffer())
|
|
310
|
+
console.info(obj.cid) // CID(baeaaac3imvwgy3zao5xxe3de)
|
|
311
|
+
console.info(obj.buf) // Uint8Array(5) [ 0, 1, 2, 3, 4 ]
|
|
312
|
+
```
|
|
313
|
+
|
|
314
|
+
#### DAG-CBOR
|
|
315
|
+
|
|
316
|
+
[DAG-CBOR](https://ipld.io/docs/codecs/known/dag-cbor/) uses the [Concise Binary Object Representation](https://cbor.io/) format for serialization instead of JSON.
|
|
317
|
+
|
|
318
|
+
This supports more datatypes in a safer way than JSON and is smaller on the wire to boot so is usually preferable to JSON or DAG-JSON.
|
|
319
|
+
|
|
320
|
+
##### Content-Type
|
|
321
|
+
|
|
322
|
+
Not all data types supported by `DAG-CBOR` can be successfully turned into JSON and back into the same binary form.
|
|
323
|
+
|
|
324
|
+
When a decoded block can be round-tripped to JSON, the `Content-Type` will be set to `application/json`. In this case the `.json()` method on the `Response` object can be used to obtain an object representation of the response.
|
|
325
|
+
|
|
326
|
+
When it cannot, the `Content-Type` will be `application/octet-stream` - in this case the `@ipld/dag-json` module must be used to deserialize the return value from `.arrayBuffer()`.
|
|
327
|
+
|
|
328
|
+
##### Detecting JSON-safe DAG-CBOR
|
|
329
|
+
|
|
330
|
+
If the `Content-Type` header of the response is `application/json`, the `.json()` method may be used to access the response body in object form, otherwise the `.arrayBuffer()` method must be used to decode the raw bytes using the `@ipld/dag-cbor` module.
|
|
331
|
+
|
|
332
|
+
```typescript
|
|
333
|
+
import { verifiedFetch } from '@helia/verified-fetch'
|
|
334
|
+
import * as dagCbor from '@ipld/dag-cbor'
|
|
335
|
+
|
|
336
|
+
const res = await verifiedFetch('ipfs://bafyDagCborCID')
|
|
337
|
+
let obj
|
|
338
|
+
|
|
339
|
+
if (res.headers.get('Content-Type') === 'application/json') {
|
|
340
|
+
// DAG-CBOR data can be safely decoded as JSON
|
|
341
|
+
obj = await res.json()
|
|
342
|
+
} else {
|
|
343
|
+
// response contains non-JSON friendly data types
|
|
344
|
+
obj = dagCbor.decode(await res.arrayBuffer())
|
|
345
|
+
}
|
|
346
|
+
|
|
347
|
+
console.info(obj) // ...
|
|
348
|
+
```
|
|
349
|
+
|
|
350
|
+
## The `Accept` header
|
|
351
|
+
|
|
352
|
+
The `Accept` header can be passed to override certain response processing, or to ensure that the final `Content-Type` of the response is the one that is expected.
|
|
353
|
+
|
|
354
|
+
If the final `Content-Type` does not match the `Accept` header, or if the content cannot be represented in the format dictated by the `Accept` header, or you have configured a custom content type parser, and that parser returns a value that isn't in the accept header, a [406: Not Acceptable](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/406) response will be returned:
|
|
355
|
+
|
|
356
|
+
```typescript
|
|
357
|
+
import { verifiedFetch } from '@helia/verified-fetch'
|
|
358
|
+
|
|
359
|
+
const res = await verifiedFetch('ipfs://bafyJPEGImageCID', {
|
|
360
|
+
headers: {
|
|
361
|
+
accept: 'image/png'
|
|
362
|
+
}
|
|
363
|
+
})
|
|
364
|
+
|
|
365
|
+
console.info(res.status) // 406 - the image was a JPEG but we specified PNG as the accept header
|
|
366
|
+
```
|
|
367
|
+
|
|
368
|
+
It can also be used to skip processing the data from some formats such as `DAG-CBOR` if you wish to handle decoding it yourself:
|
|
369
|
+
|
|
370
|
+
```typescript
|
|
371
|
+
import { verifiedFetch } from '@helia/verified-fetch'
|
|
372
|
+
|
|
373
|
+
const res = await verifiedFetch('ipfs://bafyDAGCBORCID', {
|
|
374
|
+
headers: {
|
|
375
|
+
accept: 'application/octet-stream'
|
|
376
|
+
}
|
|
377
|
+
})
|
|
378
|
+
|
|
379
|
+
console.info(res.headers.get('accept')) // application/octet-stream
|
|
380
|
+
const buf = await res.arrayBuffer() // raw bytes, not processed as JSON
|
|
381
|
+
```
|
|
382
|
+
|
|
383
|
+
## Comparison to fetch
|
|
115
384
|
|
|
116
|
-
|
|
385
|
+
This module attempts to act as similarly to the `fetch()` API as possible.
|
|
117
386
|
|
|
118
387
|
[The `fetch()` API](https://developer.mozilla.org/en-US/docs/Web/API/fetch) takes two parameters:
|
|
119
388
|
|
|
120
389
|
1. A [resource](https://developer.mozilla.org/en-US/docs/Web/API/fetch#resource)
|
|
121
390
|
2. An [options object](https://developer.mozilla.org/en-US/docs/Web/API/fetch#options)
|
|
122
391
|
|
|
123
|
-
|
|
392
|
+
### Resource argument
|
|
124
393
|
|
|
125
|
-
This library
|
|
394
|
+
This library supports the following methods of fetching web3 content from IPFS:
|
|
126
395
|
|
|
127
396
|
1. IPFS protocol: `ipfs://<cidv0>` & `ipfs://<cidv0>`
|
|
128
397
|
2. IPNS protocol: `ipns://<peerId>` & `ipns://<publicKey>` & `ipns://<hostUri_Supporting_DnsLink_TxtRecords>`
|
|
129
398
|
3. CID instances: An actual CID instance `CID.parse('bafy...')`
|
|
130
399
|
|
|
131
|
-
As well as support for pathing & params for
|
|
400
|
+
As well as support for pathing & params for items 1 & 2 above according to [IPFS - Path Gateway Specification](https://specs.ipfs.tech/http-gateways/path-gateway) & [IPFS - Trustless Gateway Specification](https://specs.ipfs.tech/http-gateways/trustless-gateway/). Further refinement of those specifications specifically for web-based scenarios can be found in the [Web Pathing Specification IPIP](https://github.com/ipfs/specs/pull/453).
|
|
132
401
|
|
|
133
|
-
If you pass a CID instance,
|
|
402
|
+
If you pass a CID instance, it assumes you want the content for that specific CID only, and does not support pathing or params for that CID.
|
|
134
403
|
|
|
135
|
-
|
|
404
|
+
### Options argument
|
|
136
405
|
|
|
137
406
|
This library does not plan to support the exact Fetch API options object, as some of the arguments don't make sense. Instead, it will only support options necessary to meet [IPFS specs](https://specs.ipfs.tech/) related to specifying the resultant shape of desired content.
|
|
138
407
|
|
|
@@ -177,7 +446,7 @@ Some in-flight specs (IPIPs) that will affect the options object this library su
|
|
|
177
446
|
4. [IPIP-0328: JSON and CBOR Response Formats on HTTP Gateways](https://specs.ipfs.tech/ipips/ipip-0328/)
|
|
178
447
|
5. [IPIP-0288: TAR Response Format on HTTP Gateways](https://specs.ipfs.tech/ipips/ipip-0288/)
|
|
179
448
|
|
|
180
|
-
|
|
449
|
+
### Response types
|
|
181
450
|
|
|
182
451
|
This library's purpose is to return reasonably representable content from IPFS. In other words, fetching content is intended for leaf-node content -- such as images/videos/audio & other assets, or other IPLD content (with link) -- that can be represented by <https://developer.mozilla.org/en-US/docs/Web/API/Response#instance_methods>. The content type you receive back will depend upon the CID you request as well as the `Accept` header value you provide.
|
|
183
452
|
|
|
@@ -185,7 +454,7 @@ All content we retrieve from the IPFS network is obtained via an AsyncIterable,
|
|
|
185
454
|
|
|
186
455
|
If your content doesn't have a mime-type or an [IPFS spec](https://specs.ipfs.tech), this library will not support it, but you can use the [`helia`](https://github.com/ipfs/helia) library directly for those use cases. See [Unsupported response types](#unsupported-response-types) for more information.
|
|
187
456
|
|
|
188
|
-
|
|
457
|
+
#### Handling response types
|
|
189
458
|
|
|
190
459
|
For handling responses we want to follow conventions/abstractions from Fetch API where possible:
|
|
191
460
|
|
|
@@ -194,12 +463,12 @@ For handling responses we want to follow conventions/abstractions from Fetch API
|
|
|
194
463
|
- For plain text in utf-8, you would call `.text()`
|
|
195
464
|
- For streaming response data, use something like `response.body.getReader()` to get a [`ReadableStream`](https://developer.mozilla.org/en-US/docs/Web/API/Streams_API/Using_readable_streams#consuming_a_fetch_as_a_stream).
|
|
196
465
|
|
|
197
|
-
|
|
466
|
+
#### Unsupported response types
|
|
198
467
|
|
|
199
468
|
- Returning IPLD nodes or DAGs as JS objects is not supported, as there is no currently well-defined structure for representing this data in an [HTTP Response](https://developer.mozilla.org/en-US/docs/Web/API/Response). Instead, users should request `aplication/vnd.ipld.car` or use the [`helia`](https://github.com/ipfs/helia) library directly for this use case.
|
|
200
469
|
- Others? Open an issue or PR!
|
|
201
470
|
|
|
202
|
-
|
|
471
|
+
### Response headers
|
|
203
472
|
|
|
204
473
|
This library will set the [HTTP Response](https://developer.mozilla.org/en-US/docs/Web/API/Response) headers to the appropriate values for the content type according to the appropriate [IPFS Specifications](https://specs.ipfs.tech/).
|
|
205
474
|
|
|
@@ -209,13 +478,13 @@ Some known header specifications:
|
|
|
209
478
|
- <https://specs.ipfs.tech/http-gateways/trustless-gateway/#response-headers>
|
|
210
479
|
- <https://specs.ipfs.tech/http-gateways/subdomain-gateway/#response-headers>
|
|
211
480
|
|
|
212
|
-
|
|
481
|
+
### Possible Scenarios that could cause confusion
|
|
213
482
|
|
|
214
|
-
|
|
483
|
+
#### Attempting to fetch the CID for content that does not make sense
|
|
215
484
|
|
|
216
485
|
If you request `bafybeiaysi4s6lnjev27ln5icwm6tueaw2vdykrtjkwiphwekaywqhcjze`, which points to the root of the en.wikipedia.org mirror, a response object does not make sense.
|
|
217
486
|
|
|
218
|
-
|
|
487
|
+
### Errors
|
|
219
488
|
|
|
220
489
|
Known Errors that can be thrown:
|
|
221
490
|
|