proxiedFetch
fetch 互換のラッパーで、リクエストを Fluxlay ホストプロセス経由で送信します。Access-Control-Allow-Origin を返さない network: 宣言済み origin (Google カレンダーの ICS フィードや公開 RSS など) に対して使用します。ホストが通常の HTTP クライアントとしてアップストリームへ問い合わせるため、ブラウザの CORS は適用されません。
インポート
シグネチャ
引数の形は標準の fetch API と同じです。返される Response には upstream のステータス・ボディ、および転送対象のレスポンスヘッダだけが乗ります。
使い方
対象 origin は fluxlay.yaml の network: で宣言する必要があります:
用途
壁紙は隔離された fluxlay:// origin で動作し、外向きリクエストは 2 段階のゲートで制限されます:
- CSP
connect-src: 壁紙 webview からはfluxlay.yamlのnetwork:で宣言した origin にしか到達できない。 - CORS: CSP を通っても、upstream が
Access-Control-Allow-Originを返さなければブラウザがレスポンスをブロックする。実運用の API には CORS を返さないもの (ICS / 静的ファイルホスト / 公開 RSS) が多い。
proxiedFetch は 2 番目の制約を回避します。リクエスト内容をローカル Fluxlay API (POST /v1/network-proxy) に POST すると、ホスト (Rust) が代行で fetch してボディを壁紙に返します。ホスト側 HTTP には CORS が適用されないので、network: 宣言済みの origin はすべて利用可能になります。
1 番目のゲートはそのままです — 未宣言 origin はプロキシが 403 を返すため、セキュリティモデルは直接 fetch と同じです。
標準 fetch との差分
- 受け付けるのは
http:/https:URL のみ。file:/data:/ 独自スキームは 400。 Cookie/Origin/Host/Refererリクエストヘッダは upstream に転送されない。- レスポンスボディは 10 MiB 上限。超過すると 502。
- ストリーミングレスポンスは非対応。upstream のボディは全てバッファされてから壁紙に返される。
- 転送するレスポンスヘッダは
Content-Type/Cache-Control/ETag/Last-Modifiedのみ。Set-Cookie等はドロップ。 - リクエストタイムアウト 30 秒、リダイレクト 5 ホップまで追従。
備考
init.headersのAuthorization等は upstream にそのまま転送される。トークンが壁紙 origin のストレージに永続化されることはなく、各呼び出し時にホストを通過するだけ。User-Agentを呼び出し側で指定しない場合、自動的にFluxlay-Wallpaper-Proxy/<version>が設定される。User-Agent必須の API (GitHub 等) も追加設定なしで動く。init.signalのAbortSignalは壁紙側 fetch をキャンセルする。ホスト側のリクエストはバックグラウンドで完了まで継続する。