fix: support POST-only HTTP API #1430
Conversation
ipfs/kubo#7097 will block `GET` commands on API port, switching everything to POST. This breaks Files screen in ipfs-webui as noted in #1429 ipfs-webui is using older version of js-ipfs-http-client, one before huge refactor into async iterables, which means switching to the latest version won't be a trivial task. For now, we just apply simple patch on top of ipfs-http-client v39.0.2 to ensure it sends commands as POST. Proper fix will land when ipfs-webui is refactored to work with ipfs-http-client >41.x Closes #1429
|
@Stebalien @hsanjuan |
|
@Stebalien I am not sure if patch release will be possible due to recent move to monorepo. I'd rather not bother @achingbrain with it. Keeping this fix local to webui decreases noise: everyone should be already on the latest js-ipfs-http-client >41.x anyway, its just ipfs-webui lagging behind and we have no bandwidth to upgrade it before go-ipfs 0.5. |
|
Sounds good, I trust your judgment. |
|
I created #1431 to track proper upgrade. I'll merge this and prepare a new release. |
|
@lidel thinking about this a bit, we should really release a patch release of the HTTP API. Upgrading to async/await is non-trivial so there are likely dapps other than ipfs-webui in the same boat. |
|
@Stebalien I agree, I hit into more problems while working on Companion and would really appreciate if such patch release existed. Created ipfs/js-ipfs#2971 and marked it as P0 to make sure POST-only API is properly handled on JS side, including patch release. |
Removes patching introduced in #1430 and uses ipfs-redux-bundle v7.0.0 to bring a compatible version of ipfs-http-client that is known to support POST-only HTTP API while also exposing the old JS API. Context: ipfs/js-ipfs#2971
Removes patching introduced in #1430 and uses ipfs-redux-bundle v7.0.0 to bring a compatible version of ipfs-http-client that is known to support POST-only HTTP API while also exposing the old JS API. Context: ipfs/js-ipfs#2971
Problem
ipfs/kubo#7097 will block
GETcommands on API port, requiring everything to be a POST request.This breaks Files screen in ipfs-webui as noted in #1429
Even a bigger problem
ipfs-webui is using older version of js-ipfs-http-client, one before huge refactor into async iterables, which means switching to the latest version won't be a trivial task, as the amount of code and dependencies that needs to be refactored is unknown.
Solution
Due to time constraint I made a decision to patch it in npm
postinstallso we can release this ASAP and ship with go-ipfs 0.5.postinstallscript will apply a simple patch on top of ipfs-http-client v39.0.2 to ensure it sends commands as POSTProper fix will land when ipfs-webui is refactored to work with ipfs-http-client >41.x
Closes #1429
cc @achingbrain for visibility