Hello. Has anything been updated in the icx-proxy functionality? I’m trying to execute this command: icx-proxy --address 127.0.0.1:8453 --dns-alias 127.0.0.1:rrkah-fqaaa-aaaaa-aaaaq-cai --replica http://localhost:8080 -v , but I’m getting an error: error: unexpected argument '--dns-alias' found . Does anyone have information on this?
We bumped the icx-proxy version in the latest dfx version and didn’t notice that some features were removed. We’re now considering to downgrade the version again,
The --dns-alias option has been removed since end of November 2022: feat: add flags to force certification on `_/raw/` and SEO paths · dfinity/ic@2ca2d2d · GitHub
What is your use-case? I guess you are trying to call 127.0.0.1 and get forwarded directly to the canister. What client do you use?
Thanks for the quick response. I am working on enabling the staking of a neuron, the controller of which is a canister. Since I cannot use inter-canister calls (ic_cdk::call ), the only option I see is to use HTTP out calls in combination with threshold_ecdsa . Specifically, at the moment, I am looking for a way to test my changes on a local replica. For this, I need to invoke the ‘manage_neuron’ method of the governance canister using the ‘http_request’.
I see. So you are trying to make an HTTP outcall to 127.0.0.1:8453 (localhost) and want that call to be forwarded to the canister.
I am not sure if the following will work for your setting/with HTTP outcalls, but that’s what works for me (with the latest version):
icx-proxy --address 127.0.0.1:8453 --replica http://localhost:8080 --canister-alias ic:oa7fk-maaaa-aaaam-abgka-cai --domain example.com
Then, I can curl with:
curl http://ic.example.com:8453 --resolve ic.example.com:8453:127.0.0.1
Now, you cannot add --resolve to the HTTP outcalls. Therefore, it might work by just locally setting example.com to resolve to 127.0.0.1 in /etc/hosts.
+1 @Severin
My use case looks like this:
Canister 1:
- Canister that accepts
http_request - Works like a rest api, serves different things on
http://url/1andhttp://url/2etc
Canister 2:
- Asset canister with frontend
- Wants to load image from canister 1,
<img src="http://url/1"/>
Works great on ic network but difficult to test locally because of ?canisterId=.
Dream would be that the default setup gives every canister a subdomain alias on localhost. 
canister1.localhost
canister2.localhost
Buut, I guess that would be difficult to automate?
1 Like
Doesn’t it already work like this? We use canister id subdomains on localhost almost always, it’s the default method we use and what we encourage and show everyone in our documentation.
Does this format not work for you? http://[canisterId].localhost:[port]
1 Like
Subdomains on localhost are not supported by Safari. Using query parameters does not always work in Chrome, according to my experience.
The pragmatic current solution is a mix of both, as for example documented in II’s README:
To access Internet Identity or configure it for your dapp, use one of the following URLs:
Chrome, Firefox: http://<canister_id>.localhost:4943
Safari: http://localhost:4943?canisterId=<canister_id>
Mentionning this assuming you are speaking about opening a dapp on a local replica with dfx.
Wow, I did not know this! 
This is great.
I quickly scanned the docs (the IC docs, not Azle), and couldn’t find this mentioned almost anywhere. I would have assumed this to be the default choice for accessing canisters, as it more closely mimics the URL when deployed to IC. However, the reasons @peterparker lists are good arguments against promoting a setup that doesn’t work on all browsers.
I’ll just stay off of Safari (didn’t use it in the first place) and live happily ever after.
1 Like
Because it’s just for local testing I feel like the Safari issue isn’t as much of a problem…and this should be promoted more as the default and the Safari issue can be mentioned as the exception.
Agree, really. The default http://127.0.0.1:4943?canisterId=<canister_id> becomes a headache as soon as you do anything querystring related in the frontend. So, that is probably causing issues for most IC frontend development, while the Safari issue likely is experienced only by a few. Safari is not big with developers afaik.
1 Like
And any dev who uses Safari, probably on desktop if they’re testing with a local replica, should have access to Chrome, FireFox, etc if they really need it. With the http://127.0.0.1:4943?canisterId=<canister_id> you get problems kind of everywhere.
@Severin can we get this changed? I think it’s really worth considering showing the localhost subdomains as the defaults for the reasons explained in the past few comments, and this issue has come up elsewhere.
I think it’s not about which one should be the default; the discussion should be about why it is that way and whether it could be fixed or improved with another approach that works cross-browser.