i read a couple of posts here that suggested to run icx-proxy locally to access for example an asset in an asset canister through the http interface.
but it seems like icx-proxy is already running with dfx start as the name of the terminal window suggests and also the fact that one can access assets using this URL format
http://localhost:8000/<your_asset_path>?canisterId=<your_canister_id>
so my question would be if this is a new change to dfx or if you have any other advantages if you run another explicit instance of icx-proxy.
maybe @jzxchiang or @ericswanson can help.
Hmm, how do you know dfx start runs icx-proxy? I remember reading that it ran some other HTTP server not called icx-proxy.
Up to now, I’ve been running dfx replica in one terminal and icx-proxy in another.
I assume this from the fact that I’m able to access assets from an asset canister through the above mentioned URL and the fact the running dfx stop leads to this console output:
dfx stop
Dec 20 12:10:23.373 INFO Caught SIGTERM
Stopping the replica...
Stopped.
Stopping icx-proxy...
Stopped.
Another hint is that when running dfx start the terminal window is named icx-proxy.
1 Like
It’s relatively new to dfx that dfx start launches icx-proxy in order to translate http requests to calls to the replica. You can run more instances of icx-proxy if you want, but there shouldn’t be any advantages for local development.
2 Likes
Ah interesting, is this since 0.8.3?
As far back as dfx 0.7.3 actually.
1 Like
When running dfx replica in one terminal, the companion that will run icx-proxy is dfx bootstrap. But unless you have a specific reason to run them separately, I’d recommend dfx start which will take care of both.
1 Like
