Is it possible to make calls from and reverse?

I want to make a request from my application to another application via an unsafe API (, 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://***
  • make fetch('https://***')
  • Got error URL "https://***" 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 * and *

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://***, 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 *, 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.


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
  • open the console
  • we make a request to the same canister in raw domain zone fetch('')
  • 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.


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):


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


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!


I just ran into this issue here:

I am currently sharing 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


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.

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


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

1 Like