Is it possible to make raw.ic0.app calls from ic0.app and reverse?

I want to make a request from my application to another application via an unsafe API (ic0.raw.app), but I get an error. Is this the target behavior?

It seems that the Service worker did not resolve a canister ID from another domain URL.
Steps to reproduce:

  • Go to https://***.ic0.app
  • make fetch('https://***.raw.ic0.app/index.html')
  • Got error URL "https://***.raw.ic0.app/" did not resolve to a canister ID.

After debugging I found, that service worker unable to resolve canisterId when page hostname does not match requesting URL. Difference is between *.ic0.app and *.raw.ic0.app.

It’s blocker for me because I want to check certificated assets from raw resource before the load a resource in IFrame. And this is the last way to solve my problem after Why can’t IFrame be used with certificated URLs?

Please, help or answer

1 Like

Also, there is no way to register custom service worker on https://***.ic0.app, because any request to main domain is accompanied by bootstrap-page loading instead of a custom worker JS-source.

Will us be able to register out custom service workers in future?

I’m surprised: When accessing *.raw.ic0.app, no service worker should be involved. The point of raw is that it hits the HTTP Gateway on the boundary node and no certificate checking happen, so no reason to have a service worker involved.

2 Likes

This applies to requests from the frontend, where the service worker is already installed. For example

  • go to any canister (for example go to OpenChat https://7e6iv-biaaa-aaaaf-aaada-cai.ic0.app/)
  • open the console
  • we make a request to the same canister in raw domain zone fetch('https://7e6iv-biaaa-aaaaf-aaada-cai.raw.ic0.app')
  • got error, Network tab is empty

Good analysis. That sounds like a bug in the service worker to me – it should let raw urls through.

3 Likes

Roger! :slight_smile:
Any suggestions who can help with this issue?

1 Like

It should be sufficient to extend this check, to let requests to raw urls through (just like requests to unrelated domains):

2 Likes

And I still could not find the sourcecode (sorry). Thank you so much for the link!
Perhaps I’ll open a pull request :slight_smile:

1 Like

@kpeacock Check plz
Pull request

3 Likes

Pull request was merged.
@bitdivine @kpeacock Thanks you so much! :heart:

1 Like

We appreciate the initiative, and thanks for bearing with us while we’re in the middle of migrating the serviceworker to a new codebase!

6 Likes

I just ran into this issue here: https://ic3o3-qiaaa-aaaae-qaaia-cai.ic0.app/

I am currently sharing https://ic3o3-qiaaa-aaaae-qaaia-cai.raw.ic0.app/ instead to get around this. All of the audio elements fail without .raw in the URL address bar.

1 Like

As far as I can see the audio works and it’s great! :slightly_smiling_face:
If you want to use audio elements without .raw, try to certify uploaded files in the same way as certified-assets or cert-var. I haven’t tried it, but it should work.
Thank you for your feedback! :metal:

1 Like

I thought I responded to this, I fixed it up unregistering the service worker, I think it was out of date. Service workers often seem to have a problem staying up to date

this happens because the audiofile is splited into chunks. When service-worker fetching chunk and trying to validate it, worker compares file hash from field sha256 with chunk hash. And of course they don’t match. When file was not chunkified, service-worker loads file at once and hashes match.

I plan to post a topic about it

1 Like

Or make streaming implementation on service-worker

UPDATE

We’re a couple sprints in, and I’ve still been focused on the invoice canister. I’d still like to demonstrate chunking via agent-js, but that won’t resolve the basic issue of the serviceworker needing streaming support

1 Like

I have a similar question, not about streaming
Is it correct to use merkletree hashing algorithm while uploading chunks into certified_assets and make support of this on service-worker?

At now, not chunkified files works correctly (fetch(...), <img src...>) in the browser, but downloading chunkified files raises 500 validation error.

To fix this, I want to try:

  • calculate and save merklethee of chunks to sha256 field of certified_assets (by yourself)
  • [Service-worker improvement] make equal(sha, treeSha)-function to validate merkletree (because treeSha is a hash of chunk and merkletree is usually used for validating chunk hashes)

Ideally, this will allow to using chunkified assets at least in simple fetch or <img src=...> cases.

Hi, Kyle! :slight_smile:

I created a PR with my proposal about streaming support.

I will be grateful for the review.

PS
Unfortunately, this proposal does not solve @lastmjs problem with continuous streaming, but it allows you to download assets larger than 2mb through service-worker

2 Likes

very cool, this is going to be super helpful! thank you for taking the time to fix this

1 Like