fix(public): serve /favicon.ico from the canonical SVG so legacy clients stop 404-ing - #238
Conversation
…nts stop 404-ing The /favicon.ico fallback path was 404-ing on every legacy / crawler / screenshot request because the asset bucket only contains public/favicon.svg and isAssetLikePath send the request to asset_not_found. This branch: - Adds /favicon.ico to PUBLIC_ASSET_PATHS and a dedicated branch in the worker handler that pulls the canonical /favicon.svg bytes via env.ASSETS and re-serves them with Content-Type: image/x-icon and Cache-Control: public, max-age=31536000, immutable. - Adds two source-side guards in scripts/check-site.mjs so a future refactor that drops either the allow-list entry or the content-type override exits npm run check non-zero (the fallthrough back to 404 becomes a guarded regression, not a silent loss). The single <link rel="icon" href="/favicon.svg"> in every served page is unchanged, so modern browsers continue to use the canonical SVG; the new handler only fires for clients that ignore the <link> and fall through to the well-known path. Verification: npm run check exits 0, wrangler deploy --dry-run bundles cleanly, all eight test suites stay green, and wrangler dev + curl on the local port returns HTTP 200 with the canonical SVG bytes and Content-Type: image/x-icon. Receipt: docs/evidence/favicon-ico-2026-08-17.md Lane report: .lane/reports/fix-favicon-ico-2026-08-17.md
|
You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard. |
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
There was a problem hiding this comment.
Your trial has ended. Reactivate Greptile to resume code reviews.
|
Warning Review limit reached
Next review available in: 28 minutes Limit details: You’ve used all 1 included review currently available under your plan. Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Free Run ID: 📒 Files selected for processing (4)
Note 🎁 Summarized by CodeRabbit FreeYour organization is on the Free plan. CodeRabbit will generate a high-level summary and a walkthrough for each pull request. For a comprehensive line-by-line review, please upgrade your subscription to CodeRabbit Pro by visiting https://app.coderabbit.ai/login. Comment |
… current main and live (2026-08-20, lane 1) (#250) Item 017eb201fc ("[unreviewed-by-opus] No rel=icon link is served, so every page load fires a 404 /favicon.ico request while favicon.svg exists and is allow-listed") is closed against current main and live. The code fixes are already merged: #85/#113 added rel=icon links to all seven served pages plus the CI guard, and #238 added the /favicon.ico legacy fallback serving the canonical SVG bytes. This receipt re-verifies the guarantee on head d0daea9 and the live site: npm run check and npm test pass, all seven pages serve exactly one /favicon.svg rel=icon link with zero /favicon.ico requests in real Chromium, and the /favicon.ico path itself now returns 200 image/x-icon with byte-identical canonical bytes. Co-authored-by: minimax-vps <minimax-vps@fleet.local> Co-authored-by: CommandCodeBot <noreply@commandcode.ai>
1 participant
Fix
Item 017eb201fc — "[unreviewed-by-opus] No rel=icon link is served, so every page load fires a 404 /favicon.ico request while favicon.svg exists and is allow-listed".
Prior re-verify receipts (PRs #132, #182, #230 — 2026-08-12, 2026-08-14, 2026-08-15) closed the observed symptom on modern Chromium by adding to every served page, but the underlying request path /favicon.ico was still answered with HTTP 404 whenever any legacy / search-engine / screenshot client asked for it. This branch lands the source-side fix so the path is no longer 404-able on the live worker.
What changed
src/worker.js
PUBLIC_ASSET_PATHSadds "/favicon.ico" with a comment explaining why the legacy path needs an explicit allow-list entry.env.ASSETS.fetch(...)and re-serves them withContent-Type: image/x-iconandCache-Control: public, max-age=31536000, immutable. Security headers continue to flow throughwithSecurityHeaders, matching every other served response.scripts/check-site.mjs
npm run checkfails non-zero if either the allow-list entry or theimage/x-iconcontent-type override is removed in a future refactor — the fallthrough back to 404 becomes a guarded regression, not a silent loss.docs/evidence/favicon-ico-2026-08-17.md — receipt recording the fix and the local HTTP probe.
.lane/reports/fix-favicon-ico-2026-08-17.md — lane-1 closeout report.
Verification
node scripts/check-site.mjs→ exit 0, "TinyStudio.io checks passed."wrangler deploy --dry-run→ exit 0, bindings registered cleanly.wrangler dev --local --port 8791+curl /favicon.ico→ HTTP 200,Content-Type: image/x-icon, body SHA-256 =998e43ad83f78adcd8a75fb37a87657ba2289b760470f42583c7fab166d9184c(matchespublic/favicon.svg).GET /favicon.ico?v=1all return 200; POST correctly returns 404 (only GET/HEAD are supported on static asset paths).What did not change