Is there a way to get the raw url to work with custom domain?

Developers
1

Hi everyone :slight_smile:

In order to explain is better to share some links first:

  1. .raw.icp0.io works perfectly

    image
    image1905×1032 170 KB

  2. .icp0.io doesn’t work

    image
    image1908×837 35.5 KB

  3. br.elementum.one doesn’t work

    image
    image1914×827 33.4 KB

I’m guessing that the domain registration within the boundary node is pointing to the regular url (.icp0.io) and that’s why br.elementum.one is not working.

Then, is there a way to get the raw url to work with custom domain?

2

Hi @CapuzR

There are ultimately two “browser” endpoints on the boundary nodes:

  • service worker (e.g., <canister-id>.icp0.io), where you get a service worker, which then will make all the API calls to the IC and check asset certification. The service worker rejects any asset that is not properly certified.
  • raw (e.g., <canister-id>.raw.icp0.io), where your requests are passed through icx-proxy (basically a service worker running on the boundary node).

The big difference between the two endpoints is that icx-proxy only enforces asset certification if a certificate is present. Hence, some sites load over raw, but not through the service worker.

When you use a custom domain, you hit the service worker endpoint. At the moment, it is not possible to point your custom domain to a raw endpoint.

If you are using the standard asset canister, all the response verification is already implemented for you and your site should work over the service worker endpoint as well. Is there a reason why you are not using the asset canister?

2 Likes
3

You’ll have to run your own ICXProxy instance…if you do that you can serve raw.

1 Like
4

Hey, are there any good motoko examples, for implementing ceritification headers in a motoko canister?
I have seen an old example implementation by nometa, but I am not sure it’s even working now or not, also if there are any advance implementations, that would be too helpful.

1 Like
5

Hey @h1teshtr1path1

@kpeacock created the Motoko server (more info here). He put the certification into a base library certified-cache (here), which relies on @nomeata’s ic-certification (here) that you mentioned.

2 Likes