Discrepancy between webr 0.4.2 self-hosted release and remote https://webr.r-wasm.org/0.4.2/

[JeremyPasco]

Hi, I'm having troubles with self-hosting webR.

The following works:

const webR = new WebR()
await webR.init()
await webR.evalR(`webr::install('readxl')`)

const buff = await file.arrayBuffer() //file created previously
let arr = new Uint8Array(buff);
await webR.FS.writeFile("data.xlsx", arr)
const res = await webR.evalRRaw('readxl::excel_sheets("data.xlsx")', 'string[]')

DevConsole shows that the following repo is used: https://webr.r-wasm.org/0.4.2/

But hosting webR locally triggers some strange error. With:

const webR = new WebR({baseUrl: "https://localhost:9000/webr/bin/"})

I get no network error, all webR dependancies are loaded successfully.

But I get an error without message when executing the readxl line:

To host webR binairies, I simply put the whole webr/dist of the 0.4.2 release into a directory accessible from: https://localhost:9000/webr/bin

Http headers have been set to allow SharedArrayBuffer, but switching to PostMessage channelType makes no difference.

Is there any difference between the last release and the remote webr binaries fetched by default that could explain this?

[JeremyPasco]

I compared checksum of remote and local files and found no difference.
Clearing all caches didn't help.
Does webr handle local and remote baseUrl differently somehow?

[georgestagg]

Hi,

Thanks for reporting this! I think I have been able to reproduce the issue, or a related one at least. In particular, it looks like a relative baseUrl does not currently work. This seems to be a regression, as it definitely worked in the past.

Though, saying that, I notice your baseUrl is not relative, but it does have https://. Is that correct? It's fine if so, I just wouldn't expect a local testing server to use SSL certificates, instead I would expect to see http://.

As a temporary workaround, in the following example I load the webR binaries from a URL relative to the root of the server (using a leading /), which seems to work well. Could you try loading webR in the same way? Be sure to include the trailing slash, it is required.

const webR = new WebR({
    baseUrl: '/webr/bin/',
});

(async () => {
  await webR.init();
  const txt = await webR.evalR('"Hello, World!"');
  console.log(await txt.toString());
})();

[JeremyPasco]

Hi, thank you for the exploration!
I use quasar framework (vuejs) which embed a self-signed SSL certificate solution for local testing, so https is indeed correct here.

Using baseUrl: '/webr/bin/' gives me the same scenario with the exact same error.

Just to be clear:

• webr.init() works with https://localhost:9000/webr/bin/ and /webr/bin/
• webR.evalR('"Hello, World!"') and the following log also work with both urls (so the full test code you provided works)
• then, installing any package works fine with both baseUrl
• but the following line only works with https://webr.r-wasm.org/0.4.2/ : const res = await webR.evalRRaw('readxl::excel_sheets("data.xlsx")', 'string[]')

[JeremyPasco]

As explained here #511 vite server doesn't serve gz files properly if not configured specifically to do so.
When using readxl, I noted that a share.data.gz file was fetched and stayed "pending".
I hosted webr locally behind a caddy server on another port. But now I get the following error:

NetworkError: Failed to execute 'importScripts' on 'WorkerGlobalScope': The script at 'https://localhost/webr/bin/R.bin.js' failed to load.

Does that mean webr has to be hosted on the same port ?

[JeremyPasco]

Ok, now everything works fine with:

• a local vite server on port 9000 serving the app
• a local Caddy server on port 443 serving the R binaries and the repo (including gz vfs files)

Adding the following rules to my Caddy server made it work:

header {
	Access-Control-Allow-Origin "localhost:9000"
	Cross-Origin-Resource-Policy: "cross-origin"
	Access-Control-Expose-Headers: "Accept-Ranges, Content-Encoding" #works without but hides browser console errors
}

@gzip_files {
    path_regexp \.gz$
}
header @gzip_files Content-Type "application/octet-stream"

So my understanding is:

• many common web servers serve gz files with a Content-Type that webr refuses, hence the rule to rewrite it. Needed for R binaries in some cases where gz files are fetched (like vfs/usr/lib/R/share.data.gz) and to mount gzipped vfs images
• R binaries can be hosted on another domain if Access-Control-Allow-Origin allows it but also needs Cross-Origin-Resource-Policy: "cross-origin"

Is it correct ?

[JeremyPasco]

There might be some other configuration issue. One of my scripts triggered access to the following webr ressource: vfs/usr/share/fonts/NotoSansMono-Regular.ttf
Despite the exact same http headers with the ones I get with the offical repo, I had this error:

The ttf file was created but had only 2 blank octets on R filesystem.

Out of desperation, I just put a random Content-Type for .ttf files and it worked. I don't get why, but serving locally .ttf files with font/ttf as Content-Type fails for me but works perfectly with the official baseUrl. So here is my new Caddy configuration:

header {
	Access-Control-Allow-Origin "localhost:9000"
	Cross-Origin-Resource-Policy: "cross-origin"
	Access-Control-Expose-Headers: "Accept-Ranges, Content-Encoding" #works without but hides browser console errors
}

@strange_files {
    path_regexp \.gz$|\.ttf$
}
header @strange_files Content-Type "application/octet-stream"