dag.put does not work in the js ipfs daemon with cbor-style input, even though the same request works with go-ipfs

[pcowgill]

I'm creating this issue here for a ipfs-http-client problem since this repo is turning into a monorepo.

Error when doing this:

const cbor = { foo: "dag-cbor-bar" };

const cid = await ipfs.dag.put(cbor, {
  format: "dag-cbor",
  hashAlg: "sha2-256"
});

That's similar to what is done in the dag.put tests, so it should be working.

This error occurs in a browser env, for instance when using js-ipfs-http-client from a create-react-app app

Found the root of the issue by hitting a local js-ipfs daemon in debug mode DEBUG=ipfs* js-ipfs-local daemon where js-ipfs-local is my zsh alias for the local js-ipfs version.

The problem is in borc via js-ipld-dag-cbor.

https://github.com/dignifiedquire/borc/blob/b6bae8b0bcde7c3976b0f0f0957208095c392a36/src/decoder.js#L547

On the browser side, it looks like this:

Uncaught (in promise) HTTPError: Input too short
    at errorHandler (http://localhost:3000/static/js/0.chunk.js:15327:17)
    at async fn (http://localhost:3000/static/js/0.chunk.js:12038:36)
    at async Promise.Ky.result.<computed> [as json] (http://localhost:3000/static/js/0.chunk.js:12074:19)
    at async Object.put (http://localhost:3000/static/js/0.chunk.js:13484:17)
    at async dagPut (http://localhost:3000/static/js/main.chunk.js:147:17)

[pcowgill]

This is what the request looks like when it reaches the handler in the js-ipfs daemon (found this by logging inside a local version ofit-multipart which is used inside of my local version of ipfs-multipart:

------WebKitFormBoundarymvPI6Z6BIuTaKgjJ
Content-Disposition: form-data; name="file"; filename="blob"
Content-Type: application/octet-stream

�cfooldag-cbor-bar
------WebKitFormBoundarymvPI6Z6BIuTaKgjJ--

[pcowgill]

dag.put works as expected in React when pointing at go-ipfs rather than js-ipfs. So this is a js-ipfs-specific issue.

[pcowgill]

@achingbrain If you agree that dag.put isn't working with js-ipfs but it is with go-ipfs, do you think it would make sense to try to land a fix for this in the 0.42.0 release too? #2808

[achingbrain]

Yes, we should absolutely fix this bug in the next release.

[achingbrain]

I think this bug is fixed, in that we have a test that does what's in the original post and it's run against js-ipfs straight to core and over http from node and the browser, and against go-ipfs.

If you're still seeing this issue, please open a PR with a failing test case in the file linked to above.