Repairing a Cloudflare Worker canonical-URL redirect loop

Architecture and trust boundaries

A reviewable system path

First-party repair — simplified routing diagram based on the documented failure and production fix.

1. STEP 1 / 4

   Canonical browser request

2. STEP 2 / 4

   Worker host/path policy

3. STEP 3 / 4

   Direct env.ASSETS.fetch(request)

4. STEP 4 / 4

   Static response + restrictive headers

Engineering walkthrough

A short original visual explainer of the technical problem and the control boundary involved.

Problem

• The edge Worker requested /index.html and /services.html while the asset layer redirected these requests to / and /services.
• The Worker forwarded those redirects to visitors. Each new request retriggered the same lookup, creating an infinite redirect cycle.
• Changing the site's button CSS did not fix or explain the routing defect; application presentation and edge routing were separate concerns.

Engineering work

• Traced the Location headers on the apex host, www host and individual route paths to isolate the redirect source.
• Changed asset lookup to use the incoming canonical request directly with env.ASSETS.fetch(request), eliminating the .html rewrite.
• Aligned Cloudflare's html_handling with drop-trailing-slash so exported HTML can be requested by its canonical URL.
• Validated the fix in an isolated checkout before publishing the Worker, keeping unrelated local changes untouched.

Engineering validation

• Built the Next.js static export and ran the existing automated tests.
• Exercised /, /services, /contact, /robots.txt, /sitemap.xml and an unknown path against a local Worker.
• Checked successful pages returned HTTP 200 without loops, unknown paths returned HTTP 404, and the www hostname redirected to the apex.
• Repeated those checks against the public hostname following deployment.

Results

• The public homepage, service pages and contact page returned HTTP 200 without circular redirects.
• The canonical www-to-apex redirect and the intended 404 behavior remained intact.
• The fix restored normal page serving and canonical routing. We did not measure business or uptime impact.

Check today's public route behavior

The archived HTTP observations are reproducible using a public client. They confirm current behavior, not the original historical failure or independent customer delivery.

curl -L -o /dev/null -w "%{http_code} %{num_redirects}
" https://demonicbinary.com/services
curl -L -o /dev/null -w "%{http_code}
" https://demonicbinary.com/not-a-published-page-for-routing-test

Related engineering stories