Keep unique origins distinct
04Some inputs receive a fresh unique origin rather than a triple. Turning that origin into the text null loses its identity.
A later check uses the document’s stored A: A equals itself, A differs from B, and A differs from a scheme/host/port triple. Do not compare only their printed null strings.
Source for this drawing: RFC 6454 · Read RFC section 4 ↗
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
These pictures are analogies to help you learn. The linked RFC explains the actual rules.
Terms in this drawing
Related RFCs and changes
“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.
Two strings saying null do not prove two origins are the same.
- A URI without the required hierarchical authority, a non-absolute URI, or an unsupported protocol receives a fresh globally unique identifier in the RFC’s §4 algorithm.
- The same data URI can produce different identifiers on separate computations. Typically a document’s origin is computed once and retained for later checks, rather than regenerated on every check.
- A unique origin never equals a triple. Non-triple origins serialize as the four-character string null. The null header value can also represent an application-designated privacy-sensitive context (§7.3).
The circles A and B denote different opaque identities; their labels are illustrative and are not serialized identifiers. This depicts the RFC algorithm, not every modern navigation/inheritance rule. file origins are implementation-defined here; there is no universal all-files-share-one-origin rule.
Read the RFC section ↗