[Feature Request] Offline caching of assets

[liango2]

Describe the problem/motivation

Excuse me, in the event of a network outage, will nothing be displayed? How can it be displayed even offline?

When there is an internet:

When there is no internet:

Describe the solution you'd like

displayed even offline

Alternatives considered

No response

[veryard]

Hi @liango2,

The issue you're encountering is because the widget configuration you've selected relies on internet access to fetch assets. To resolve this, you'll need to either build a custom theme or modify an existing one to store the assets locally.

Happy to help develop a fully offline-compatible default theme that could be used as the default theme.

Thanks!

[lars-berger]

The issue you're encountering is because the widget configuration you've selected relies on internet access to fetch assets. To resolve this, you'll need to either build a custom theme or modify an existing one to store the assets locally.

Happy to help develop a fully offline-compatible default theme that could be used as the default theme.

Ideally the default config would be something easy + familiar, and also wouldn't require any build tools to accommodate non-programmers (e.g. node/npm). Buildless React has been the best middle ground we've found so far since it's familiar to programmers, and non-programmers don't have to install the nodejs toolchain to do simple changes

---

Re. offline support - it'd be possible to cache assets for offline use. It'd be especially nice to have offline caching of assets like webfonts and 3rd party CSS. I've looked into it a lil bit, info dumping my notes on request caching so far:

- `Window::on_web_resource_request`
    - Can’t intercept requests through `http://` and `https://` - only requests made to `tauri://` URLs.
- Service worker
    - Only works out of the box on Windows. To be able to use them on Linux and MacOS, would need to run a [localhost](http://localhost) server with the resources.
        - [Localhost](http://Localhost) Tauri plugin is recommended to work-around this, but would need to be modified to work with Zebar. https://github.com/tauri-apps/plugins-workspace/tree/v2/plugins/localhost
        - How to load the service worker? Ideally it should be loaded before the user’s HTML so that everything can be cached on first run. This can be done via `window.eval` in Rust, but how to then create a separate JS file for the service worker API. Looks very annoying.
    - Using a [`file://`](file://) protocol is not supported in any browser.
- Socks5/HTTP proxy (i.e. `window.proxy_url`)
    - Can’t handle HTTPS requests. In-flight HTTPS requests are e2e encrypted and the query params can’t be inspected.
    - When proxying `https://` requests through an HTTP proxy, the TLS exchange is forwarded through the proxy using the `CONNECT` method, so end-to-end encryption is not broken. However when establishing the tunnel, the hostname of the target URL is sent to the proxy server in the clear. https://chromium.googlesource.com/chromium/src/+/HEAD/net/docs/proxy.md#http-proxy-scheme
- Override the `https` protocol with `App:register_uri_scheme_protocol`
    - Doesn’t do anything - continues to use built-in `https` protocol handling.
- Add a custom `cache://` protocol
    - For example, `import React from 'cache://esm.sh/react@18?dev'`
    - Same as http/https but caches the request forever for offline support.
    - Base64 encode the request URL and store it in the Tauri data directory.

The best option seems to be to add a custom protocol (e.g. cache://) that then caches every request to disk (e.g. cache://esm.sh/zebar@2). This would then allow people to choose whether a request should be fetched from disk cache or fresh from the Internet

[veryard]

• Add a custom cache:// protocol
  • For example, import React from 'cache://esm.sh/react@18?dev'
  • Same as http/https but caches the request forever for offline support.
  • Base64 encode the request URL and store it in the Tauri data directory.

I had a quick look into this part specifically, please correct me if I am wrong but on Windows this will not work it would to be http://cache.{url}? Otherwise you end up with a CORs error on Windows. https://github.com/tauri-apps/tauri/blob/a8105eccb2122f003b4a36bbfb747998f53c5f10/crates/tauri/src/webview/mod.rs#L1198

Which is kind of annoying, I wonder if the http://cache.{url} would work on other platforms or we have to add some check in the code.

veryard@1f6ef2d - WIP this was just me playing around at one angle, happy to gather thoughts, we could add the Cache handler to the app state, then eventually have a clear cache button on the context menu.

Currently this dumps all files that start with http://cache. into the cache_dir(), for now I was base64ing the URL and appending the file extension, then using mime_guess to get the mime back from the extension later, this can change just an idea for now.

I believe a better approach could be a manifest file that has sha256 hash of the url then we store those and use it as the file name, happy to hear thoughts!

Can chat via Discord if that's a bit easier too: breadly

Thanks