Compute the origin triple
02For a supported HTTP or HTTPS URI, lowercase the scheme and host, use the explicit or default port, and keep those three values.
Independent example: https://picnic.example/menu has no explicit port, so its triple uses 443. It differs from the earlier 8443 example.
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.
Normalize before comparing; a missing HTTP port means 80, and a missing HTTPS port means 443.
- The §4 algorithm first handles non-absolute/non-authority URIs and unsupported protocols with fresh unique identifiers. The triple path shown here is for supported HTTP and HTTPS URIs.
- Scheme and host are lowercased. The host is assumed to have already undergone IDNA processing and validation; IDNA converts international domain labels to their ASCII forms.
- Use an explicit port when present; otherwise use the protocol’s default port. A path, query and fragment do not appear in the triple. The file scheme MAY use an implementation-defined value.
This is a bounded worked example, not a universal URI parser. IDNA algorithm differences can change security boundaries (§8.4). A URL parser’s current behavior is not used to claim full RFC 6454 conformance.
Read the RFC section ↗