-
Notifications
You must be signed in to change notification settings - Fork 106
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: download tars from @helia/verified-fetch #442
Conversation
Let users get raw data back from CIDs that would otherwise trigger decoding as JSON or CBOR etc by specifying an `Accept` header. ```typescript const res = await verifiedFetch(cid, { headers: { accept: 'application/octet-stream' } }) console.info(res.headers.get('accept')) // application/octet-stream ``` Make sure the content-type matches the accept header: ```typescript const res = await verifiedFetch(cid, { headers: { accept: 'application/vnd.ipld.raw' } }) console.info(res.headers.get('accept')) // application/vnd.ipld.raw ``` Support multiple values, match the first one: ```typescript const res = await verifiedFetch(cid, { headers: { accept: 'application/vnd.ipld.raw, application/octet-stream, */*' } }) console.info(res.headers.get('accept')) // application/vnd.ipld.raw ``` If they specify an Accept header we can't honor, return a [406](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/406): ```typescript const res = await verifiedFetch(cid, { headers: { accept: 'application/what-even-is-this' } }) console.info(res.status) // 406 ```
…ader-for-raw-types
Adds support for the `application/vnd.ipld.car` accept header to allow downloading CAR files of DAGs.
Adds support for downloading tar archives of UnixFS directories
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm
expect(entries).to.have.lengthOf(5) | ||
expect(entries[0]).to.have.nested.property('header.name', importResult.cid.toString()) | ||
|
||
expect(entries[1]).to.have.nested.property('header.name', `${importResult.cid}/${directory[1].path}`) | ||
await expect(toBuffer(entries[1].body)).to.eventually.deep.equal(directory[1].content) | ||
|
||
expect(entries[2]).to.have.nested.property('header.name', `${importResult.cid}/${directory[2].path?.split('/')[0]}`) | ||
|
||
expect(entries[3]).to.have.nested.property('header.name', `${importResult.cid}/${directory[2].path}`) | ||
await expect(toBuffer(entries[3].body)).to.eventually.deep.equal(directory[2].content) | ||
|
||
expect(entries[4]).to.have.nested.property('header.name', `${importResult.cid}/${directory[0].path}`) | ||
await expect(toBuffer(entries[4].body)).to.eventually.deep.equal(directory[0].content) | ||
}) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
the order here seems odd.. should ${importResult.cid}/${directory[0].path}
be at entries[1] ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Alex let me know it-tar handles ordering and it's stable, so it should be fine.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There's some interesting discussion on tar file ordering here: https://unix.stackexchange.com/questions/120143/how-is-the-order-in-which-tar-works-on-files-determined
Either way, it's external to @helia/verified-fetch
.
name: file.path, | ||
mode, | ||
mtime, | ||
size: Number(file.size), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
do we want to squash the bigint from Exportable.size
to a Number here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We have to convert it because it-tar
expects the field to be a number.
We may lose some precision but Number.MAX_SAFE_INTEGER
is 9PB so famous last words but I think files of that size may be uncommon.
Co-authored-by: Russell Dempsey <1173416+SgtPooki@users.noreply.github.com>
…om-verified-fetch
Adds support for downloading tar archives of UnixFS directories