Running into the problems described here: Dfx 0.7.0-beta.2 does not allow ES modules, and I am trying to figure out how to get this all to work using a local http proxy for now.
For a GET request, how does the replica know which canister to get the assets from? Inspecting some of the traffic, it seems like it must be the Referrer http header, because not all GET requests have the canisterId appended to their paths.
I’m playing with this locally but getting 500 errors from dependencies of my ES modules.
Okay I think I figured it out, it’s got to be the Referer header. When I set that to the empty string I get a 500, and when I manually put a canisterId into it I don’t get 500 errors anymore.
So ES modules are indeed unsupported currently with the v0.7.0 beta, since the Referer does not have the canisterId. I am assuming other things besides ES modules are broken, essentially whenever a request is not originating from the route index.html file, there might be a possibility of this being broken.
1 Like
Sorry, late repsonse, but it’s not the referrer. Eventually it will be the Host (canister-id.ic0.app); for local development a query parameter ?canister_id=abcde-fgh is used.
I’m sorry, but are you sure it’s not the referer locally? Like I explained in my previous post, I get 500 errors when the referer header does not have the canisterId query parameter in it.
The problem is, many requests locally do not have the canisterId query parameter anywhere in the headers that I can see. If you look through some of my other posts, I’ve explained that ES module transitive import requests do not have the canisterId query parameter anywhere in the request. These requests fail. But when I put the canisterId query parameter into the referer header (using a proxy), the requests succeed.
My experiments locally do not match what you’re saying, so I have to disagree.
Or, I can’t square what you’re saying with what I’m seeing locally I guess. What am I doing wrong? I assume you would be able to replicate my issues locally
Best solution I’ve found is to use http://canisterId.localhost:8000 and to mostly develop on chrome, which supports localhost subdomains, or else to use Webpack dev server
2 Likes
That would be odd; I don’t see any code using the referrer in any component that could play a role here, and I never heard about this.
Maybe the requests you are seeing without the url query parameter are not GET request to /api/…, which are interaction with the internet computer?
For GETs to assets, the canister id must come from somewhere, and as far I know, that is either the query parameter, or the hostname (as @kpeacock points out). If you obsere something else I’d be curious to have more detail, e.g. a dump of the request as captured from the dev console.
Cool, I’ll see if I can get more information
Looks like you were right and I was wrong, to some extend.
In local development the proxy ran by dfx start will indeed look for the canister id in the following locations:
- Hostname
- Query string
- Referrer
The latter two are only needed for local development where you can’t easily have separate hostnames per canister; for the real deployment, the hostname should always be indicative.
Sorry for being thick-headed here!
5 Likes
Oh cool, yeah it’s no problem at all! Thanks for getting back to me on this
1 Like
This seems to work for now, I’ll update this thread if there are any issues with using localhost subdomains.
I think using localhost subdomains might be breaking update calls in development: Fail to verify certificate in development update calls
icx-proxy --fetch-root-key --address 127.0.0.1:1234 --dns-alias foo.localhost:<asset-canister-id> allows browsing to http://foo.localhost:1234 in Chrome.