Summary

  • CDN-Loop relies on intermediaries carrying an existing warning forward and preventing customer configuration from erasing it. That obligation does not authenticate the warning's contents.
  • A repeated provider identifier can reflect intended internal processing. The relevant question is what recurrence means in the supported service path, not whether a brand appears twice.
  • A local protection decision, the request's actual route and the identity or intent of its originator are different claims. Treating one as evidence of all three creates a second failure.

A warning with no certificate of origin

An intermediary receives a request carrying a list of earlier intermediaries. It is expected to keep the list intact. It may also use the list to decide that accepting the request would repeat work that should have ended. Yet the list is not, merely by existing, a trustworthy account of where the request has been.

This is not a contradiction to eliminate with a reassuring adjective. It is the operating boundary of CDN-Loop. A content delivery network can contribute to a shared defence without vouching for everything another party placed in the request.

The distinction matters whenever configuration crosses providers. One customer may regard header transformation as part of the service it bought. A downstream provider may depend on a particular header surviving those transformations. Another team may be asked to explain why the origin never received the request. Those teams are discussing the same traffic but do not control the same decisions.

A hypothetical failure makes the separation visible. An application is deliberately delivered through more than one provider. A routing change introduces a return to an earlier stage. The receiving system rejects the request under its protective policy. That event tells an investigator something important about the receiving system. Without additional context, it does not establish whether the return was intended, whether every listed passage occurred, or whether anyone intended harm.

No such customer incident was tested for this report. The scenario is a way to examine a documented mechanism, not an allegation about a deployment.

Preservation is a shared dependency

RFC 8586, published in April 2019, defines the CDN-Loop request field for cooperating CDNs. It recommends appending a provider identifier to generated or forwarded requests. Its effectiveness depends on intermediaries preserving what is already there and on customers being unable to remove or modify the field through their configuration. The specification also advises against using it for other purposes.

These constraints place a limit on what “programmable” can mean at the customer boundary. The customer can own the application without owning every protective signal that application traffic carries. Removing a marker can affect a later provider, not just the service on which the transformation was configured.

That is a narrow restriction with a broad ownership consequence. The benefit of a convenient transformation can accrue locally while the loss of detection context appears elsewhere. This is an incentive analysis, not evidence that a named company permits such a transformation today.

Three decisions consequently need separate owners. Someone decides which customer transformations are allowed. Intermediaries decide how to preserve the shared field. A recipient decides what to do with the resulting contents. Saying that a product “supports CDN-Loop” does not explain how those three responsibilities survive a change in the service path.

The RFC's information record identifies it as a Proposed Standard. That status establishes neither universal adoption nor compatibility among any particular set of contracted services. The verified technical erratum corrects a reference to separate grammar rules; it does not resolve the operational ownership question.

The second visit may be part of the service

Counting provider names is attractive because it is easy to explain. A name appeared before; therefore the request must be looping. Unfortunately, a service can have legitimate internal stages that make this explanation too simple.

Fastly's CDN-Loop reference, accessed on 8 September 2026, describes up to four Fastly tokens depending on clustering and shielding. This is a bounded statement about that provider's documented processing. It is not a safe allowance for every service, nor a suggested threshold to copy into another network.

Its analytical significance is more durable than the number. A repeated provider identifier need not mean that the commercial path has returned to its beginning. The provider name can be a coarser unit than the processing stages inside the service.

Cloudflare's current header documentation, updated on 5 May 2026, describes using CDN-Loop to limit entry into its network. Its 20 March 2019 account also discusses legitimate repeated processing associated with subrequests. The earlier post is a provider's historical explanation; the current documentation is not a measurement of every customer's effective configuration.

Together these sources support a question, not a vendor ranking: what is the intended unit of recurrence in this particular path? Adding a shielding layer, changing an internal handoff or introducing a subrequest can change the answer without changing the supplier names in the procurement record.

A commercial diagram with two boxes may therefore omit precisely the distinction a protection rule needs. It can be adequate for assigning invoices and inadequate for diagnosing a rejected request. Neither diagram is necessarily wrong; they describe different objects.

Carrying an assertion does not endorse it

The trust boundary is explicit in RFC 8586: any client can generate the field, so its contents cannot be trusted. A provider that changes behaviour in response must avoid creating another denial-of-service opportunity. Signing is possible, but this specification neither defines nor requires a signing scheme. The field and the reactions to it can also disclose a provider's presence or internal configuration.

The operational implication is not to discard the field. Discarding it would damage the very cooperation on which the mechanism depends. It is to keep the claim made by the field smaller than the claim made by an incident report.

A protection log can establish that a configured condition caused a local action, assuming the log itself is reliable. It cannot automatically certify each alleged preceding hop. It says even less about who caused the condition or whether the cause was malicious.

An investigator may ultimately establish those things from other evidence. The mistake is making them prerequisites for a useful local defence, or treating the defence as if it had established them already. Protection and attribution have different evidential burdens.

The same distinction applies to an identifier that resembles a familiar organisation. Recognisability helps a human read a list; it does not turn a supplied string into the organisation's attestation. A hostname can avoid some accidental naming collisions without proving the history of the request that carries it.

The origin's silence needs context

When a request is stopped earlier, the origin may have no matching arrival to explain. Absence at the origin is compatible with several upstream outcomes. It does not tell the origin team which component acted or whether the protective action was correct.

A useful diagnostic record would connect the local rule, the relevant configuration version and the intended service stages. This is an editorial operating proposal, not an additional RFC requirement. It seeks enough context to distinguish a changed route from a changed interpretation of the route.

The record need not become a complete public map of the delivery infrastructure. More detail is not automatically better evidence. Internal stage names can create disclosure costs while still failing to authenticate the preceding path. Access, purpose and retention need to match the question being investigated.

There is also a limit to what a successful repair demonstrates. If requests resume after a configuration change, that supports an operational explanation of the interruption. It does not retrospectively prove every assertion in the earlier field. Restoration and attribution should remain separate findings.

What the documents do not establish

The available sources specify a mechanism and describe selected implementations. They do not supply an adoption census, a present attack rate, a comparative reliability score or the effective rule for a particular customer. This report did not generate loops, modify customer services or observe production requests.

Lu Heng's essay on the agency problem in Internet governance offers a useful question about the separation of authority and exposure. Applying that question here is the author's analysis, not an extension of the essay's registry-specific claims to CDNs. His account of reality rather than advocacy as BTW Media's product similarly argues for examining constraints before endorsing institutions.

The constraint here is unusually precise. A provider has to carry a warning across a boundary without promoting it into a certificate. The quality of the arrangement depends on who preserves that distinction when configuration, topology or incident responsibility changes.