Problems loading source maps, and images referenced in `manifest.json`

I’m using a canister with "type": "assets" and seeing the following:

Screen Shot 2022-09-01 at 1.06.53 PM

Screen Shot 2022-09-01 at 1.08.21 PM

Has anyone else experienced this?

If I use curl on these URLs I get the HTML for the service worker. I assume is what’s happening in the above screenshots but if I browse to those URLs the files load in my browser.

I see that Open Chat is using /_/raw/ for some things in its index.html file but not in its application manifest (view-source:, or similar)

This all works locally so I’m assuming it’s related to certification and the service worker.

As an aside, I’d prefer to get ahead of issues like this by having my local development environment also run the service worker but I haven’t looked into doing that yet.

Your findings are correct.

Long story short, the IC ( core domain) does not support crawlers yet. That’s why, if you want your meta data - such as icons defined in the <head /> of your index.html or manifest file - to be interpreted correctly, the domain (or shortcut /_raw/) can be used as a workaround (as OpenChat, NNS-dapp and all my dapps do).

On the secure domain, any requests is intercepted by the service worker which takes care of executing the calls and certifying that it is secure. This works as intended in the browser but, does not when a curl is performed or when a crawler request a resources. As you noticed, the answer is the one page that loads the service worker but, nothing happens afterwards because well, there are no service worker in that context.

This is a known limitation - or issue depends the point of view :wink: - and various scenario and tasks are open and on going about it. I did not check recently what are the status therefore cannot really tell spontaneously where they stand.


Thanks @peterparker.

I was wondering how doesn’t use raw URLs but I just realized that doesn’t work and has the same issues I’m seeing.

I’m not sure how I’m going to tell esbuild how to special case all of these problematic URLs but I guess I’ll look into that.

If I remember correctly OC use the /_raw/ domain to load their custom service worker.

In NNS-dapp, if it can help, we just reference the manifest.json from root. Nothing particular. On the contrary, Icons and manifest icons are specified through the raw domain. This to solve the issue you shared but also because otherwise, when installing the dapp on mobile devices (iPhone), the icons would not be interpreted (iOS uses a crawler to get the icons it seems).

Hope that help, let me know if you have more questions (might answer tomorrow though, it’s late here :wink:).

1 Like

For some reason /_/raw/ isn’t working for my canister. Is there anything I need to do to enable that?

Apparently that no longer works.

That makes things a bit more complicated because now I can’t just prepend /_/raw/ to relative asset paths.

Ummm a bit suprised it does not work anymore because OC still uses it on mainnet to load their service worker

On the contrary, as I do, they load the asset from the domain. Can you also try this?

Wondering if the latest updates for crawlers will allow me to revert back to non-raw URLs.

I just tried with NNS-dapp on a testnet. It did not work out but, I may have missed something. I will ping my colleagues to find more information and will comeback to this thread.

1 Like

Turned out I was testing on a deprecated testnet which does not fully support the new feature. However I cannot test yet with NNS-dapp on a new testnets because these are not yet accessible through a valid SSL. My collleagues using curl confirmed it worked out though.

But I’m a frontend developer, I believe what I click and see :wink:. So I’ll wait for the full test and will update the thread when I’ll will do so (can take a bit of time).

1 Like