You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
fix: content-type response header hints how to process response (#426)
## JSON codec
```TypeScript
import { verifiedFetch } from '@helia/verified-fetch'
import * as json from 'multiformats/codecs/json'
const res = await verifiedFetch('ipfs://bafyJSONCodec')
// get object representation of JSON body
console.info(await res.json()) // { ... }
// alternative way to do the same thing
const obj = json.decode(new Uint8Array(await res.arrayBuffer()))
console.info(obj) // { ... }
```
## DAG-JSON codec
```TypeScript
import { verifiedFetch } from '@helia/verified-fetch'
import * as dagJson from '@ipld/dag-json'
const res = await verifiedFetch('ipfs://bafyDAGJSONCodec')
// get spec-compliant plain-old-JSON object that happens to contain a CID
console.info(await res.json()) // { cid: { '/': 'Qmfoo' } }
// ...or use @ipld/dag-json to get rich-object version
const obj = dagJson.decode(new Uint8Array(await res.arrayBuffer()))
console.info(obj) // { cid: CID('Qmfoo') }
```
## DAG-CBOR codec
```TypeScript
import { verifiedFetch } from '@helia/verified-fetch'
import * as dagCbor from '@ipld/dag-cbor'
const res = await verifiedFetch('ipfs://bafyDAGCBORCodec')
if (res.headers.get('content-type') === 'application/json') {
// CBOR was JSON-friendly
console.info(await res.json()) // { ... }
} else {
// CBOR was not JSON-friendly, must use @ipld/dag-cbor to decode
const obj = dagCbor.decode(new Uint8Array(await res.arrayBuffer()))
console.info(obj) // { ... }
}
```
If the `DAG-CBOR` block contains anything that cannot round-trip to JSON (e.g. `CID`s, `Uint8Array`s, `BigInt`s, etc), the content type will be `application/octet-stream` - `.json()` will throw and so `@ipld/dag-cbor` must be used to decode the resolved value of `.arrayBuffer()`.
---------
Co-authored-by: Daniel Norman <1992255+2color@users.noreply.github.com>
Co-authored-by: Daniel N <2color@users.noreply.github.com>
Co-authored-by: Russell Dempsey <1173416+SgtPooki@users.noreply.github.com>
Copy file name to clipboardexpand all lines: README.md
+205-6
Original file line number
Diff line number
Diff line change
@@ -13,9 +13,24 @@
13
13
14
14
# About
15
15
16
+
<!--
17
+
18
+
!IMPORTANT!
19
+
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
+
16
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.
17
32
18
-
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.
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/).
19
34
20
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.
By default, `@helia/verified-fetch` sets the `Content-Type` header as `application/octet-stream` - this is because the `.json()`, `.text()`, `.blob()`, and `.arrayBuffer()` methods will usually work as expected without a detailed content type.
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.
130
145
131
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.
132
147
@@ -140,14 +155,198 @@ import { fileTypeFromBuffer } from '@sgtpooki/file-type'
140
155
141
156
const fetch =awaitcreateVerifiedFetch({
142
157
gateways: ['https://trustless-gateway.link'],
143
-
routers: ['http://delegated-ipfs.dev'],
158
+
routers: ['http://delegated-ipfs.dev']
159
+
}, {
144
160
contentTypeParser: async (bytes) => {
145
161
// call to some magic-byte recognition library like magic-bytes, file-type, or your own custom byte recognition
146
-
returnfileTypeFromBuffer(bytes)?.mime
162
+
const result =awaitfileTypeFromBuffer(bytes)
163
+
returnresult?.mime
147
164
}
148
165
})
149
166
```
150
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.
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*asdagJsonfrom'@ipld/dag-json'
259
+
260
+
const block =newTextEncoder().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:
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:
[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.
3. CID instances: An actual CID instance `CID.parse('bafy...')`
167
366
168
-
As well as support for pathing & params for item 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).
367
+
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).
169
368
170
369
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.
0 commit comments