ipfs-http-client: Does not work with older versions of ipfs-core/ipfs-http-server

[stephhuynh18]

• Version: 0.12.2

• Platform: Darwin Stephanies-MacBook-Pro.local 20.6.0 Darwin Kernel Version 20.6.0: Wed Nov 10 22:23:05 PST 2021; root:xnu-7195.141.14~1/RELEASE_ARM64_T8101 arm64

Description:

The latest ipfs-http-client(^56.0.1) does not work with older versions of ipfs-core(~0.12.2) and ipfs-http-server(~0.9.2). I ran into the issue when trying to use ipfs-http-client with a dockerized ipfs instance that utilized an older version of ipfs-core (https://hub.docker.com/r/ceramicnetwork/ipfs-daemon). It fails with the following error:

HTTPError: Failed to parse the JSON: SyntaxError: Unexpected token � in JSON at position 0
    at Object.errorHandler [as handleError] (---/codepad/node_modules/ipfs-http-client/esm/src/lib/core.js:75:15)
    at processTicksAndRejections (node:internal/process/task_queues:96:5)
    at async Client.fetch (---/codepad/node_modules/ipfs-http-client/node_modules/ipfs-utils/src/http.js:144:9)
    at async Object.put (---/codepad/node_modules/ipfs-http-client/esm/src/dag/put.js:27:19)
    at async example (---/codepad/lib/with-old-ipfs-core.js:31:17)
    at async main (---/codepad/lib/with-old-ipfs-core.js:8:5) {
  response: Response {
    size: 0,
    timeout: 0,
    [Symbol(Body internals)]: { body: [PassThrough], disturbed: true, error: null },
    [Symbol(Response internals)]: {
      url: 'http://127.0.0.1:52846/api/v0/dag/put?store-codec=dag-cbor&input-codec=dag-cbor&hash=sha2-256',
      status: 400,
      statusText: 'Bad Request',
      headers: [Headers],
      counter: 0
    }
  }
}

Is this the desired behavior? Should ipfs-http-client be compatible with older version of ipfs-core?

Steps to reproduce the error:

Demo found here --- https://github.com/stephhuynh18/demo

[rvagg]

There was a breaking change in the DAG API specifically at 0.10 (at least on the Go side, it took a little while to migrate to js-ipfs). So this is known and intentional - there's currently no means to feature / version detect on this API but I don't imagine it's out of the question to sniff how to deal with that API if you could come up with an elegant way (@achingbrain will have opinions and input on this if you're considering pursuing it). #3917

I think you should be able to take your version down one semver-major (55.x) and get a client that's compatible with older APIs.

[lidel]

Action here is to update dependency to the latest version of js-ipfs.