POST-only HTTP API

[lidel]

Problem

go-ipfs 0.5 will block GET commands on the API port (ipfs/kubo#7097), requiring every command to be sent as HTTP POST request (makes it a true RPC + solves some security issues).

🔍 Ensure ipfs-http-client works with API without GET

• I think it does: interop tests run by go-ipfs CI passed,
  but would appreciate second pair of eyes to confirm I did not miss anything
• We should have tests that fail if GET is accepted by /api/v0 on API port
  unsure where to add those, any ideas?

😅 Ship a patch release for old JS API?

Blocking GET broke Files screen in ipfs-webui as noted in ipfs/ipfs-webui#1429 (comment)

ipfs-webui is using older version of ipfs-http-client, one before huge refactor into async iterables, which means switching to the latest version won't be a quick task.

I suspect there are third party projects which use older version of ipfs-http-client but have no time to refactor entire codebase to work with the latest version. We could make it easier if we shipped a patch release with literally 7 line diff (ky.get → ky.post, as seen in seen in ipfs-http-client@39.0.2.patch)

I am unsure how to do this given we moved to monorepo recently.
I think v41.0.0 of ipfs-http-client was the last release before Async Await and Async Iterables.

@achingbrain is it possible to release something like ipfs-http-client@41.0.1?
Any way I can help?

Update: ipfs-http-client@41.0.1 is ok for use (if you are stuck at old API)

[bluelovers]

this?
https://github.com/lerna/lerna/tree/master/commands/version#--allow-branch-glob

[achingbrain]

I am unsure how to do this given we moved to monorepo recently.

The history from merged repos has been maintained so it should just be a case of making a branch from the last ipfs-http-client release commit, making the changes, doing the release and pushing the updated branch back to the repo.

[lidel]

Good news: turns out ipfs-http-client@41.0.1 exists – it was the last version which provided the old JS API, but on the backend was refactored to use new one, and in the process all ky.get calls were replaced to ky.post (I checked all 7 problematic ones).

This means we don't need to make any patch releases – ipfs-http-client@41.0.1 is POST-only already.

---

What remains to be done is to convert API exposed by js-ipfs to match behavior of go-ipfs more closely (POST-only, additional Origin/Referer check, load webui from API port instead of gateway).

@achingbrain my plan is to implement the above before I jump into #1877, if that is okay with you?

[achingbrain]

Sounds good, thanks @lidel

[achingbrain]

This has been fixed in js-ipfs by #2977

[achingbrain]

..and released in js-ipfs@0.43.0 and js-ipfs-http-client@44.0.0

[lidel]

Thank you! Continued in:

• go-ipfs 0.5 release: Go-IPFS 0.5.0 Release kubo#7109
• switching ipfs-desktop to ipfs-http-client@44.0.0 happens in feat: update ipfsd-ctl to 4.x ipfs-desktop#1411
• refactoring ipfs-companion to the new client and API is tracked in Migration to JS API with Async Await and Async Iterables ipfs-companion#843