Custom asset canister does not provide files as raw

Hi,

I have a custom asset canister using the ic_certified_assets crate.
I can upload and get my assets as expected and also access them via http request.

However, I can’t access the files raw through the http request for whatever reason, I always get redirected first.
Example: https://ojkmg-riaaa-aaaag-aal6a-cai.raw.ic0.app/image.png

As far as I can tell, the uploaded assets look fine to me:

@jzxchiang
@lastmjs
@kpeacock
@coin_master

You seem to have worked a lot with custom asset canisters, maybe you people or someone else in this forum has an idea what I’m doing wrong. Thank you!

2 Likes

The above link worked for me.

https://ojkmg-riaaa-aaaag-aal6a-cai.raw.ic0.app/image.png appears to be getting redirected to https://ojkmg-riaaa-aaaag-aal6a-cai.ic0.app/image.png

Exactly, that is the problem. Updated the sentence in the initial post to make it more clear. AFAIK the point of “raw” is to get the file directly without the validation response and redirect.

I think this intentional:

I don’t think so.
I have a completely custom asset canister where I can access the raw file without validation or redirect.
Example: https://o4n5l-qaaaa-aaaag-aal5q-cai.raw.ic0.app/

But I want to avoid having to write each canister from scratch where I want to use the asset canister interface :smiley:

Also, if you deploy assets with the icx-asset you can also access the files “raw” via http.

I assumed that the above meant that the following code was in effect:

It is not. In order to make the canister an asset canister the only things I did are:

  • call ic_certified_assets::init(); in canister init function
  • add asset canister types to candid

Nothing else. Do i need to add something?

Update: Temporarily “solved” the problem by downgrading ic-certified-assets to version 0.1.0 before the code piece mentioned by @paulyoung was implemented.

Works now, but this is not an ideal solution. If someone knows how to disable the redirect any input is still highly appreciated :slight_smile:

1 Like

I don’t have any experience with ic_certified_assets and I’m surprised that it works if all you’re doing is calling init in your canister init so I’m not sure what to suggest.

Could you help me understand why you want to access files via raw?

I think the only motivation I’ve heard for that so far is that people hadn’t yet done the work to support certified responses, and the asset canister seems to take care of that already.

I want to host the files in a way that they are available to arbitrary applications. Some of the apps I tested do not like the redirect and I don’t want to exclude them.

Is there a problem with providing those applications with the non-raw URLs?

Yes. I can retest it to assure but some apps were unable to retrieve the files.

The intention was that, since there were no instances where the ic0.app URL would cause problems that the raw.ic0.app URL did not, there was therefore no point in allowing the possibility of a malicious response. It sounds like you are saying that there are such instances. Can you provide more details about the errors or problems with using the certified endpoint?

Maybe some services aren’t following redirects.

I am super busy with finishing my Hackathon submission right now but I can offer you to dig up an example on tuesday and share it here if you are interested.

Can you share any portion of the code repo which you used this for? I am having trouble using icx-asset upload and integrating the ic-certified-asset crate. There is so much here for me to unpack. Are the image and audio encoded in the pem file? They are then subdirectories of the canister?

1 Like