Front end Assets randomly fail to load with 500, other times it loads fine

The same assets load at times… also the smaller assets load always from the error messages

For example the 40mb one was loading fine last night and might load again later

40MB is consistently failing for me

i can ascertain that the asset loads at times…

this is what is confusing me.

any idea how I can work around this limitation?

the same asset, if I change it to raw.ic0.app it does load…
how can I make the front end call the raw URL instead?

What do you think?

https://rbsr6-fyaaa-aaaai-aarwa-cai.ic0.app/resources/guard/castle_guard_01.fbx does not load
https://rbsr6-fyaaa-aaaai-aarwa-cai.raw.ic0.app/resources/guard/castle_guard_01.fbx does indeed load

the overall workflow is.

  1. For raw URL xxxx.raw.ic0.app
    the flow bypasses the service worker so there is NO content signature verification.

  2. For the non-raw URL xxxx.ic0.app
    this call goes through the service worker that performs the verification after downloading the complete asset. the service worker keeps aside memory to download the asset, if this memory is not enough to store the complete asset (as in your case) the verification bails out.

Do you really need the asset verification, can this requirement be relaxed ? If so then, a workaround would be to fetch via the raw endpoint. Of course, this is a temporary workaround. Once streaming is implemented you can switch back to using the service worker (aka non-raw endpoint)

2 Likes

Thanks a lot for the detailed overview.

However I am not sure how to fetch from the raw.ic0.app endpoint in the code

One way I can think of is to hardcore the raw ic0 link where I am loading the asset, however I’m not sure if it’s the best idea.

I have also seen apps where all the assets are loaded (with a loading screen) which I would like to implement.

If you can point me to some code where this is being done, that would be super helpful.

Thanks for your help once again

2 Likes

One way I can think of is to hardcode the raw ic0 link where I am loading the asset, however, I’m not sure if it’s the best idea.

Yes, that’s what I am suggesting, i.e. you change the fetch URL to xxx.raw.ic0.app.

It’s not a solution, but avoids the worst-case scenario where you are not able to upload/download large assets

2 Likes

I havent got around to trying this yet… Will update here once i try it

When a canister sets certified_data , does it request a canister signature? Is this how the internet identity canister signs the delegation to the session key? tagging @bjoern aswell

Yes. See the system API in the interface specification. The system call ic0.certified_data_set sets a 32-byte value (which is usually the root of a Merke tree) and the ic0.data_certificate_* methods are used to retrieve the subnet signature on that value. This is exactly how canister signatures are specified, and this is how II (or any other canister) can sign delegations.

4 Likes

seems to be working fine when I use the xyz.raw.ic0.app instead of xyz.ic0.app - the assets are now loading from the raw url, and that seems to be doing the trick so far!

Thanks for all your suggestions

1 Like