Service worker mode: "cors" might break inline images on self-hosted instances with S3 storage

[puffo]

Hi everyone! I think I may have picked up a problem with the fairly recent changes to the service workers behaviour related to fetching Rails active storage variants.

Problem

Inline images in comments/cards return "FetchEvent.respondWith received an error: Returned response is null" on self-hosted instances using S3-compatible storage (Hetzner Object Storage in my case). Clicking images to download them works fine, only inline rendering is broken.

Root Cause

The service worker rule for Active Storage (service_worker.js.erb:38-48) uses fetchOptions: { mode: "cors" }:

TurboOffline.addRule({
  match: /\/rails\/active_storage\//,
  handler: TurboOffline.handlers.networkFirst({
    cacheName: "storage",
    maxAge: 60 * 60 * 24 * 7,
    networkTimeout: 2,
    maxEntrySize: 2 * 1024 * 1024,
    maxEntries: 500,
    fetchOptions: { mode: "cors" }
  })
})

This was added in commit 9a86c7cb with the note: "The load balancer now returns a specific Access-Control-Allow-Origin instead of a wildcard." This works on 37signals' SaaS infrastructure where the load balancer injects CORS headers on the 302 redirect response.

On self-hosted/Once instances there is no load balancer — requests go directly through kamal-proxy, which doesn't inject CORS headers and has no configuration option (as far as I'm aware) to do so. The flow is:

1. Service worker intercepts image request with mode: "cors"
2. Rails returns a 302 redirect to the S3 presigned URL (cross-origin)
3. The 302 response has no Access-Control-Allow-Origin header (no load balancer to add it, and kamal-proxy doesn't support custom response headers — see kamal-proxy#62)
4. The browser treats this as an opaque redirect → response is null on Webkit browsers, and a more explicit "has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource." in Chrome browsers.
5. FetchEvent.respondWith fails

Verification

• Unregistering the service worker immediately fixes image loading
• Images work in private browsing windows (no service worker registered)

Environment

• Once/self-hosted Fizzy deployment
• Hetzner Object Storage (S3-compatible, Ceph-based)
• S3 bucket CORS is correctly configured (preflight OPTIONS returns proper headers, but actual GET responses from Hetzner/Ceph don't include CORS headers on presigned URLs)
• kamal-proxy (basecamp/kamal-proxy:once-01) — no load balancer in front

Possible Fixes

• Gate mode: "cors" behind Fizzy.saas? in the service worker template
• Fall back gracefully when the CORS fetch fails (e.g., retry without mode: "cors")
• Expose a configuration option for self-hosted instances

Ideally, it'd be best to keep the extra maxEntrySize enforcement and avoid reverting to the credentials: "omit" approach, but I'm curious for whether this is a problem for others and what the best way to fix it might be?

[puffo]

FYI, commit 45d165749 (April 8) confirms the team is aware of the exact CORS+Active Storage pattern we're hitting. That fix was specifically for development with MinIO.

The production self-hosted case with S3-compatible storage on a different domain is still broken.

[flavorjones]

@puffo Sorry for not responding sooner. If you'd like to open a pull request that adds/removes the CORS option from fetchOptions, it would be welcome. Since the service worker configuration is an ERB file it should be relatively straightforward to implement by checking ENV["SERVICE_WORKER_CORS_ENABLED"] or something similar.

Or, if you've already opened a pull request, tag me and I'll review.

[puffo]

No problem at all. Thank you, I've opened a pull request per your suggestion, here:
#2932