Skip to content

Technical research

Cloudflare Worker redirect loop: an annotated production incident

First-party analysis of a Cloudflare Worker static-asset redirect loop, its narrow fix, canonical route checks and release regression evidence.

Published 2026-11-06 · By

What actually broke on this site

Demonic Binary's own production static website experienced a redirect loop. The Worker requested exported asset paths such as /index.html and /services.html, while the Cloudflare asset layer normalized those URLs back to the public canonical / and /services paths. The next Worker request repeated the same rewrite.

This is a documented first-party routing incident, not an external client engagement, a security breach or a measured business outage. A successful Next.js compilation did not prove that edge routing, static asset resolution and redirects agreed.

Validation checklist

  • Capture the exact public paths and repeatable symptom.
  • Inspect a Location header without following unlimited redirects.
  • Distinguish static asset normalization from application UI rendering.

Trace the request across the Worker and asset layer

Compare the homepage, a service URL, robots.txt and the www hostname. A cycle in Location headers reveals which side is normalizing a route. When debugging an edge platform, inspect both source rewrite rules and the provider's html_handling configuration rather than guessing at a React rendering problem.

For this issue, the correction used env.ASSETS.fetch(request) with the incoming canonical URL, removing the redundant .html rewrite. The Worker configuration aligned exported HTML behavior with drop-trailing-slash. This is the narrowest correction supported by the observed trace.

Validation checklist

  • Homepage should return 200 at its canonical path.
  • Unknown routes must return 404, not loop or silently return home.
  • www-to-apex redirect must still resolve.

Release testing had to verify the actual environment

The deployment was validated in an isolated checkout with source, Worker and static assets together, then the same route checks were applied to the public hostname. Because Worker routing depends on hosting semantics, a mock-only unit test cannot establish that the CDN asset layer behaves correctly.

Make test expectations stable: HTTP status, redirect budget, canonical hostname and missing-route behavior. Copy and layout can change without being a site outage; test linked paths rather than outdated editorial headings.

Validation checklist

  • Record build artifact and source revision provenance.
  • Smoke-test /, /services, /contact, robots and sitemap.
  • Check failures and reversibility before deployment.

Outcomes and limitations

After the correction, the public homepage, services and contact routes returned HTTP 200, canonical redirects behaved as expected and unknown paths produced HTTP 404. Those observations support a narrow engineering result, not a percentage uptime or revenue claim.

The case study explains a repeatable investigation technique for static sites and Cloudflare Worker environments. Other platforms may normalize paths differently, so reproducing the same fix without tracing the current hosting configuration would be unsafe.

Validation checklist

  • Keep canonical routing smoke tests in CI and post-deploy QA.
  • Do not infer availability across regions from a single browser test.
  • Keep every public claim tied to verifiable evidence.

Primary references

Engineering practices and threat-model choices, not product certification, a guarantee against compromise or a customer penetration-test result.

Follow a related topic