The CDN edge isn’t just caching your static assets; it’s a powerful, programmable layer that can intercept and rewrite incoming requests before they even hit your origin server.
Imagine a user requests /products/widget-blue-123. Your backend expects this as /api/v1/items?sku=widget-blue-123. We can tell the CDN to make that transformation on the fly.
Here’s a typical scenario: your application deployed to a serverless function expects a specific URL structure, but your marketing team wants a more user-friendly, SEO-friendly URL for a new campaign.
Origin:
GET /api/v1/items?sku=widget-blue-123 HTTP/1.1
Host: myapp.example.com
Desired User URL:
https://cdn.example.com/deals/super-widget-deal
We want to map https://cdn.example.com/deals/super-widget-deal to https://myapp.example.com/api/v1/items?sku=widget-blue-123.
This is achieved through Edge Functions or Request Rewriters, depending on your CDN provider. For example, with Cloudflare Workers, you’d write a small JavaScript function. With Akamai, you might use their Property Manager rules.
Let’s look at a Cloudflare Worker example:
addEventListener('fetch', event => {
event.respondWith(handleRequest(event.request))
})
async function handleRequest(request) {
const url = new URL(request.url);
if (url.pathname === '/deals/super-widget-deal') {
const newUrl = new URL('https://myapp.example.com/api/v1/items');
newUrl.searchParams.set('sku', 'widget-blue-123');
const newRequest = new Request(newUrl.toString(), request); // Preserve method, headers, etc.
return fetch(newRequest);
}
// If no rewrite, fetch from origin
return fetch(request);
}
This code intercepts any request to /deals/super-widget-deal. It then constructs a new Request object pointing to your origin server with the correct API path and query parameter, and crucially, it passes the original request’s method (GET, POST, etc.) and headers along. The fetch(newRequest) then sends this modified request to your origin. If the path doesn’t match, the fetch(request) line sends the original request unchanged.
The core concept is that the CDN edge acts as a proxy. It receives the request, applies your logic, and then forwards a potentially modified request to your origin. This allows you to:
- Improve SEO: Map complex backend routes to clean, human-readable URLs.
- Decouple Frontend/Backend: Change your backend URL structure without breaking frontend links or requiring app code changes.
- A/B Testing: Serve different versions of a page or API endpoint based on URL parameters or headers, all managed at the edge.
- Legacy URL Migration: Redirect old URLs to new ones seamlessly.
The critical lever you control is the matching logic (the if (url.pathname === ...) part) and the transformation logic (how you build the newUrl and newRequest). You can match on path, query parameters, headers, cookies, and even the request method. You can rewrite paths, append query parameters, remove them, set new headers, or even completely change the target origin for specific requests.
Most CDNs allow you to define these rules using a graphical interface or a configuration file. The underlying principle is pattern matching and substitution. You define a pattern (e.g., /old-path/*) and then define a template for the new URL (e.g., /new-path/$1). The wildcard * captures parts of the original URL, and $1 (or similar syntax) inserts those captured parts into the new URL.
A common pitfall is forgetting to pass through original headers or the request method. If your backend API relies on specific Authorization headers or expects a POST request, simply rewriting the URL path won’t be enough. The new Request(newUrl.toString(), request) pattern in the Worker example is key here, as it copies the original request’s method and headers to the new request. Without this, you might find your POST requests turning into GET requests, or authentication failing.
The next thing you’ll want to explore is how to handle caching for these rewritten URLs.