Skip to content

fix(desktop): forward cache headers in media proxy#549

Merged
tlongwell-block merged 1 commit into
mainfrom
dawn/media-proxy-cache-headers
May 12, 2026
Merged

fix(desktop): forward cache headers in media proxy#549
tlongwell-block merged 1 commit into
mainfrom
dawn/media-proxy-cache-headers

Conversation

@tlongwell-block
Copy link
Copy Markdown
Collaborator

Why

Images re-download on every channel switch. The relay already sends
Cache-Control: public, max-age=31536000, immutable for content-addressed
media (see crates/sprout-relay/src/api/media.rs), but the desktop's
localhost media proxy and sprout-media:// protocol handler both forward
only a hard-coded allowlist:

content-type, content-range, accept-ranges, content-length

Everything else — including Cache-Control — is stripped, so WKWebView
treats every response as uncacheable.

What

Forward cache-control, etag, and last-modified in both code paths
in desktop/src-tauri/src/media_proxy.rs.

Media URLs are sha256-addressed, so honoring the upstream's immutable
caching directive verbatim is safe — the content at a given URL cannot
change. etag and last-modified are forwarded for future-proofing.

Verification

  • just desktop-tauri-check passes.
  • just desktop-tauri-fmt-check passes.
  • Full e2e build/test was skipped on push; reviewer should run pre-push
    hooks before merge (just ci).

Risk

Low. The change is additive — three more header names in a forwarding
allowlist. No behaviour change for responses where the relay doesn't
send the headers.

@tlongwell-block
Copy link
Copy Markdown
Collaborator Author

Codex review (gpt-5.5)

Ran codex review --base main -c model="gpt-5.5" against this PR.

Verdict: No findings.

The change only forwards cache-related response headers through the existing media proxy paths and does not introduce any evident correctness, security, or compatibility regressions.

(Codex inspected both proxy paths, the relay-side cache-control source in crates/sprout-relay/src/api/media.rs, and the path validation logic; it had no comments to leave.)

WKWebView fetches images via the localhost media proxy and the
sprout-media:// protocol handler. Both paths only forwarded a hard-coded
allowlist of headers (content-type, content-range, accept-ranges,
content-length) and stripped everything else — including
`Cache-Control`, which the relay already sets to
`public, max-age=31536000, immutable` for content-addressed media.

Without those headers WKWebView treats every response as uncacheable
and re-fetches every image on each channel switch.

Forward `cache-control`, `etag`, and `last-modified` in both proxy
paths. Media URLs are sha256-addressed, so the upstream's immutable
caching directive is safe to honor verbatim. `etag`/`last-modified`
are forwarded too in case the relay ever starts sending them.

Signed-off-by: tlongwell-block <109685178+tlongwell-block@users.noreply.github.com>
@tlongwell-block tlongwell-block force-pushed the dawn/media-proxy-cache-headers branch from 99c2b59 to 8d6711d Compare May 12, 2026 18:26
@tlongwell-block tlongwell-block merged commit effa24f into main May 12, 2026
15 checks passed
@tlongwell-block tlongwell-block deleted the dawn/media-proxy-cache-headers branch May 12, 2026 18:40
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant