Use case index / Cloudflare Workers
Cloudflare edge processing · thecompany-lab.com

Six edge-processing
use cases.

A single index for six F5 edge-processing patterns implemented on Cloudflare Workers. Each use case makes the normal origin and the fixed capability independently observable.

View use cases View architecture
01 · system model

Request architecture.

Every scenario follows the same observable before / after shape while keeping its policy and state local to the owning Worker.

01 · callerClientHTTPS request to a public hostname
02 · fixed stateCapability WorkerApplies the edge transform or gate
03 · before stateOrigin WorkerDirectly reachable normal fixture

Durable Objects provide strong, scoped state for S4 coordination, S5 session vaults, and S6 remediation. Web Crypto backs nonce, AES-GCM, and HMAC operations. Numeric performance results are MEASURE-NOT-CLAIM observations, never platform guarantees.

02 · use cases

Select a use case.

Open the demo for a guided view, compare the origin and Worker directly, or jump to the detailed criteria and architecture below.

03 · details

Success criteria & architecture

Each detail block summarizes what must be true and the implementation boundary that achieves it.

Scenario 01 · detail

CSP nonce injection

Turn an unprotected HTML origin into a response with one fresh, matching nonce across every eligible script.

Success criteria

  • Every eligible script receives the same per-response nonce.
  • The CSP script-src nonce exactly matches the HTML nonce.
  • Noscript scripts are not modified and transformed HTML is private, no-store.

How it is achieved

  1. 01The capability Worker fetches the public S1 origin and requests an identity response.
  2. 02HTMLRewriter applies one cryptographically random nonce to eligible script elements while a noscript depth gate remains authoritative.
  3. 03The Worker removes stale length and encoding metadata and returns the matching CSP header.
Scenario 02 · detail

Streaming HTML rewrite

Transform a roughly 10 MB report in flight without buffering the document or losing progressive delivery.

Success criteria

  • The approved script is injected once at head, body, or document-end fallback.
  • Standard HTML comments are removed through the final chunk.
  • The rewritten response has clean headers and preserves progressive delivery.

How it is achieved

  1. 01The capability Worker passes the origin ReadableStream directly into HTMLRewriter.
  2. 02Head, body, and document-end handlers provide deterministic insertion fallbacks.
  3. 03Comment events are removed as they arrive; no response.text(), tee, or full-body queue is used.
Scenario 03 · detail

TLS identity, scan, and field crypto

Use native client identity and structural data policy to sanitize JSON while leaving opaque payloads untouched.

Success criteria

  • Missing, unverified, revoked, or forged-header identity fails closed.
  • XSS, private IPs, PANs, and debug data are transformed structurally.
  • Encrypted fields use authenticated envelopes; binary bodies bypass without being read.

How it is achieved

  1. 01Cloudflare terminates client TLS and the Worker reads request.cf.tlsClientAuth; request headers never authenticate callers.
  2. 02JSON is parsed once, walked by policy, and forwarded to the HTTPS origin without logging cleartext.
  3. 03Web Crypto provides fresh-IV AES-256-GCM envelopes with AAD and key-id rotation; outbound origin certificate proof is an accepted gap.
Scenario 04 · detail

Coordinated AngularJS rewrite

Keep parallel HTML and JavaScript requests on one durable rewrite plan so the original version never escapes.

Success criteria

  • Cold HTML and parallel JavaScript requests converge on one rewrite plan.
  • Successful HTML and JavaScript responses contain no 1.8.2 marker.
  • Discovery errors return 503 rather than emitting unrewritten bytes.

How it is achieved

  1. 01One AngularVersionCoordinator Durable Object is addressed by idFromName(hostname); KV is not used.
  2. 02One discoverer fetches and publishes the complete plan before releasing waiters.
  3. 03The capability rewrites visible version markers to 1.99.9; this is obfuscation, not patching or an upgrade.
Scenario 05 · detail

Per-session cookie vault

Hide weak origin session cookies behind an opaque, authenticated browser token and a per-session Durable Object.

Success criteria

  • The browser receives only hardened __rs_sid, never PHPSESSID or AUTHTOKEN.
  • The complete origin cookie mapping is persisted before the token is issued.
  • Tampered, expired, revoked, missing, or DO-error sessions fail closed.

How it is achieved

  1. 01A high-entropy token ID selects one SessionVault Durable Object; there is no global session authority.
  2. 02The Worker strips raw client session cookies, verifies a versioned HMAC in constant time, and rebuilds the origin Cookie from vault state.
  3. 03Rotation updates the durable record and logout revokes it while preserving safe non-session cookies.
Scenario 06 · detail

Leaked-password remediation

Intercept a breached-but-valid login and guide the user through an OTP-gated, origin-authoritative password change.

Success criteria

  • Pending remediation activates only after HIBP breach detection and V1 credential validation.
  • The edge never persists a login password, new password, or password-derived verifier.
  • CSRF, Turnstile, OTP limits, password policy, HIBP, origin reset, and pending clear run in order.

How it is achieved

  1. 01HIBP receives only a five-character SHA-1 prefix; errors fail open to normal origin login.
  2. 02PendingRemediation stores metadata and OTP hashes in a per-email Durable Object; the authoritative verifier remains at the origin.
  3. 03The Worker verifies Turnstile, calls the scoped origin reset API, and clears pending only after reset success.