RFC 8586 / START HERE
CDN loop detection, before the details
CDN means Content Delivery Network: a service that handles requests in front of an origin. RFC8586 defines the CDN-Loop HTTP request header.
CDN-Loop carries a list of CDN identifiers. A forwarding CDN can look for an earlier appearance of its own identifier and add its next entry, helping it notice when a request comes back.
The idea in one picture
Append a CDN ID
Preserve the list
Check a return
A simplified picture of the idea; the chapters explain the actual mechanisms.
Why it exists
An origin can use several CDNs. A routing mistake or malicious configuration can make them forward a request in a cycle. A shared field lets participating networks preserve a record instead of continually sending the request around.
A familiar example
Imagine A forwarding to B, then B incorrectly forwarding back to A. The recorded A/B identifiers can help A stop another forward under its policy. Clients can forge the field, preservation depends on the whole path, and the RFC defines no universal visit limit or response code.
Helpful background
You can start here without reading another RFC. If these ideas are unfamiliar, these short introductions may help.
What you’ll learn next
Begin with chapter one, or choose a topic.
- Recognize a returning requestA Content Delivery Network (CDN) forwards requests on behalf of an origin service. If CDN A forwards to CDN B and a bad route sends B back to A, repeated forwarding can form a loop. CDN-Loop records CDN identifiers so a participant can notice an earlier visit. The names and stopping policy here are fictional examples.→
- Read identifiers and parametersCDN-Loop is a comma-separated list of cdn-info entries. Each starts with a CDN identifier and can carry semicolon-separated key=value parameters. An identifier can use uri-host with an optional port, or a token pseudonym. Commas inside quoted parameter values do not separate entries. All examples use reserved fictional names.→
- Append and preserve the fieldA participating CDN preserves existing CDN-Loop information and adds its own entry. The list can be extended with a comma or another field line. Customer configuration cannot be allowed to remove or rewrite the loop record if the mechanism is to function. The example shows a third CDN named c.example.→
- Use a policy without trusting the inputAny client can send CDN-Loop. A CDN must account for forged values when deciding what to do, so a spelling match alone cannot authenticate a visit. The RFC leaves detection policy and response status unspecified. The second state shows only a counting-policy illustration, not a secure implementation recipe.→
- Keep the mechanism’s limits visibleCDN-Loop addresses a particular operational loop problem; it does not replace Via or erase HTTP intermediary obligations. A non-participating CDN that strips the field can undermine downstream detection. Forwarded identifiers can also expose a CDN’s presence, hostnames or internal hop count.→
This introduction explains RFC 8586 (2019). Read the original RFC ↗