Visual RFC.
ALL RFCs / RFC 8586
Read the RFC ↗
RFC 8586 / Forwarding without loops

Keep the mechanism’s limits visible

05

CDN-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.

DIAGRAMRead RFC section 1.1 ↗
RFC 8586 · § 1.1EXAMPLE
3 / 3
Keep the mechanism’s limits visibleThe first independent example carries both Via and CDN-Loop, retaining their separate semantics and existing HTTP forwarding obligations. The second counterexample shows a non-participant removing a prior marker so a downstream CDN can miss it; this is not conforming recommended behavior. The final example exposes fictional internal hostnames in the list to a recipient. CDN-Loop neither replaces Via nor promises confidential or authenticated topology.Participation and information boundariesForwarderRecipientrequest metadataCDN-Loop: edge17.a.example, edge23.a.exampleHostnames and hop count can reveal topologyFictional internal nodes · not private by syntax
03
See the information exposure

Fictional edge17.a.example and edge23.a.example identify internal nodes in a forwarded list. A recipient can learn topology information; this base header is not encrypted or authenticated by its syntax.

Source for this drawing: RFC 8586 · Read RFC section 1.1 ↗

Protocol participantThreat or exceptionProtocol controlSimplified drawings · precise section references
New to this? Start hereA quick picture + helpful background

A message needs an address.

Think of a packet as a small addressed envelope. Devices pass it onward; transport protocols decide what delivery promises an application gets.

Helpful first, if these ideas are unfamiliar

RFC 9110 HTTP RFC 1034 DNS

These pictures are analogies to help you learn. The linked RFC explains the actual rules.

Terms in this drawing
Via
The HTTP field describing forwarding intermediaries and protocol capabilities; CDN-Loop does not replace it.
Topology
The arrangement of systems or hops in a forwarding service.
Non-participant
An intermediary that does not preserve the behavior on which this mechanism relies.
Related RFCs and changes

“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.

KEY POINT

Useful loop metadata is neither complete history nor private topology information.

  • RFC8586§1.1 explains why Via was not reliably used for this operational need. It does not deprecate Via or remove its forwarding requirements; current Via semantics are in RFC9110§7.6.3.
  • A CDN that lets customers remove or modify CDN-Loop remains an attack vector against implementing and non-implementing CDNs. Do not infer that one supporting CDN makes an entire path safe.
  • CDN-Loop can expose a CDN’s presence and internal configuration, such as hostnames and hop count. It does not promise confidentiality.
  • RFC8586 registers CDN-Loop for HTTP as a request header field. Its metadata does not configure routing, set cache policy or define a hop-count ceiling.
DETAILS

The stripping scene is a counterexample showing a non-participant, not behavior recommended for a conforming CDN. Every hostname shown is fictional.

Read the RFC section ↗

All chapters in RFC 8586

Drawing view

Scroll the drawing to see every part. Playback controls stay above it.

RFC 9700 / CHAPTERS

Chapters

For full details, tables, algorithms, and exceptions, read the original RFC.

RFC status and corrections ↗