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.
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
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.
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?
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?