WEB / WEB-22.01

From URL to a secure connection

Connect URL records, DNS knowledge, routes, transport, and peer identity in one public read plan.

CORE · RED · BLUE · ARTIFACT · PRACTICE

Read every scenario without motion

New connection

Navigation intent
The browser knows https://public.example.invalid/notes/tea?view=compact#details. The resolver has received no question; this initial state sends neither a DNS query nor an HTTP request.
Browser
Raw URL ready
Resolver
No question yet
Connection context
No connection
Peer identity
Peer unknown
HTTP planner
No HTTP plan
Parsed URL fields
The browser separates host from target, keeps the fragment out, and prepares the resolver question.
Browser
Host known; DNS question prepared
Resolver
No question yet
Connection context
No connection
Peer identity
Peer unknown
HTTP planner
No HTTP plan
Resolver question
The conceptual DNS question arrives at the resolver; the browser retains its prior prepared state.
Browser
Host known; DNS question prepared
Resolver
Hostname question received
Connection context
No connection
Peer identity
Peer unknown
HTTP planner
No HTTP plan
Address answer ready
The resolver prepares the supplied local documentation-address answer; the browser does not yet know it.
Browser
Host known; DNS question prepared
Resolver
203.0.113.10 answer prepared
Connection context
No connection
Peer identity
Peer unknown
HTTP planner
No HTTP plan
Address at browser
The conceptual DNS answer reaches the browser; resolver and other owners remain unchanged.
Browser
Parsed host and address known
Resolver
203.0.113.10 answer prepared
Connection context
No connection
Peer identity
Peer unknown
HTTP planner
No HTTP plan
Transport context
Supplied route=true and selected TCP/H2 context are evaluated; no socket or handshake runs here.
Browser
Parsed host and address known
Resolver
203.0.113.10 answer prepared
Connection context
Route true; TCP/H2 supplied
Peer identity
Peer unknown
HTTP planner
No HTTP plan
Peer identity binding
Supplied trust/path=true combines with intended ASCII hostname match=true; this is not real X.509 validation.
Browser
Parsed host and address known
Resolver
203.0.113.10 answer prepared
Connection context
Route true; TCP/H2 supplied
Peer identity
Peer predicate accepted
HTTP planner
No HTTP plan
HTTP plan ready
The dependency-gated plan carries host/path/query; neither fragment forwarding nor application permission follows.
Browser
Parsed host and address known
Resolver
203.0.113.10 answer prepared
Connection context
Route true; TCP/H2 supplied
Peer identity
Peer predicate accepted
HTTP planner
GET target plan ready; not sent

Peer mismatch

Peer check intent
Connection context is supplied; the next decision separately evaluates trust/path and intended-name binding.
Browser
Parsed host known
Resolver
Address supplied
Connection context
Transport supplied
Peer identity
Peer pending
HTTP planner
Plan pending
Chain assumption
Trust/path=true is a supplied predicate; no certificate file or cryptographic validation is executed.
Browser
Parsed host known
Resolver
Address supplied
Connection context
Transport supplied
Peer identity
Trust/path true; name unknown
HTTP planner
Plan pending
Name binding differs
other.example.invalid differs from public.example.invalid; the exact ASCII fixture match becomes false.
Browser
Parsed host known
Resolver
Address supplied
Connection context
Transport supplied
Peer identity
Name match false; peer rejected
HTTP planner
Plan pending
Request plan stopped
With peer accepted=false the selected plan is not ready, and no invented HTTP status is produced.
Browser
Parsed host known
Resolver
Address supplied
Connection context
Transport supplied
Peer identity
Name match false; peer rejected
HTTP planner
Plan false; no HTTP status

No address

Address needed
The parsed host is supplied but no usable answer exists; this ordinary fixture is not a real NXDOMAIN diagnosis.
Browser
Parsed host; address missing
Resolver
No question yet
Connection context
No connection
Peer identity
Peer unknown
HTTP planner
No HTTP plan
Missing resolver data
The resolver observation is supplied as usable address=false; no timeout or offline cause is invented.
Browser
Parsed host; address missing
Resolver
No usable answer
Connection context
No connection
Peer identity
Peer unknown
HTTP planner
No HTTP plan
Transport not started
The missing address dependency leaves transport attempted=false; no new route evidence is created.
Browser
Parsed host; address missing
Resolver
No usable answer
Connection context
Transport attempted false
Peer identity
Peer unknown
HTTP planner
No HTTP plan
Plan remains incomplete
TLS remains not-evaluated and HTTP status absent; the application handler is not considered reached.
Browser
Parsed host; address missing
Resolver
No usable answer
Connection context
Transport attempted false
Peer identity
Peer unknown
HTTP planner
Plan false; peer not-evaluated

Connection reuse

Repeated read intent
A new public read is planned for the same supplied origin; an existing connection is not yet selected.
Browser
Same origin parsed
Resolver
No question yet
Connection context
No connection
Peer identity
Peer unknown
HTTP planner
No HTTP plan
Pool context suitable
The existing connection is supplied as suitable for origin/partition/credential context; no real browser pool is read.
Browser
Same origin parsed
Resolver
No question yet
Connection context
Suitable existing H2 connection
Peer identity
Peer unknown
HTTP planner
No HTTP plan
No fresh handshake
This branch assumes a verified existing context; fresh DNS or TLS handshake stages are not portrayed as repeated.
Browser
Same origin parsed
Resolver
No question yet
Connection context
Suitable existing H2 connection
Peer identity
Existing verified context supplied
HTTP planner
No HTTP plan
Reused plan ready
The suitable existing H2 connection makes the request plan ready without a fresh DNS lookup or TLS handshake; the HTTP request has not yet been sent.
Browser
Same origin parsed
Resolver
No question yet
Connection context
Suitable existing H2 connection
Peer identity
Existing verified context supplied
HTTP planner
Plan ready; fresh DNS/handshake false

ACTORS · STATE · DATA FLOW

Address components belong to different decisions

Consider https://public.example.invalid/notes/tea?view=compact#details. Scheme, hostname, port, path, query, and fragment are not one server instruction. A URL parser separates a record; the default HTTPS port can disappear from canonical serialization. /notes/tea?view=compact contributes to the HTTP target, while #details remains client-side selection. This capstone examines the record using a URL API from the same standards family without pretending to run an address bar, history, or document navigation.

The browser initially owns the intended origin but may not know its destination address. A resolver question concerns the selected hostname and record type, not the full URL. A resolver can answer from local/cache information or consult name servers. The supplied answer uses documentation address 203.0.113.10. Arrival creates new browser knowledge: a prepared resolver answer does not mean the browser has already received it.

A DNS answer, a network route, and server identity answer different questions. IP forwarding selects next hops toward a destination; an existing DNS record does not prove reachability or application health. An unavailable route can stop connection establishment. routeAvailable is an explicit fixture predicate here, with no invented hop list, latency, or packet capture. Connecting WEB-06 and WEB-11 retains the layer from which every fact came.

Separate transport selection from the trusted peer

An HTTPS request does not require a fresh TCP handshake every time. A suitable existing connection may be reused, and a cache or service worker may answer earlier. New HTTP/1.1 or HTTP/2 connections separate TCP from TLS. HTTP/3 uses QUIC; QUIC v1 combines transport and TLS cryptographic handshakes rather than adding a TCP handshake. Protocol selection, pooling, and resumption depend on implementation policy. One animation cannot impose a universal browser timeline.

Certificate-based TLS server authentication gives the certificate chain, CertificateVerify, and Finished different responsibilities. Receiving a certificate is not validation. Trust/path/time and intended reference identity checks matter; the expected hostname comes from the intended service. DNS pointing to a different address does not automatically replace that reference identity. TLS does not grant an application user permission to a note; WEB-14 and WEB-15 still own those decisions.

The normal ledger links URL parsing, supplied resolution, route/transport selection, and supplied peer-validation results to an HTTP plan. The native example actually parses the URL but performs no lookup, socket, TLS, or X.509 validation. Its exact-name predicate covers simple ASCII aliases only, not wildcard/IDNA/IP-ID matching. The plan becomes ready only when selected dependency predicates hold. The scene ends before sending the request; peer-failed and no-address branches never become successful connections.

Read every scenario without motion

Peer name

Retain intended host
The URL selects public.example.invalid. Resolution supplies 203.0.113.10; address discovery changes neither intended hostname nor its trust binding.
URL and resolver ledger
Reference public.example.invalid / address supplied
Peer acceptance gate
Not yet evaluated
Request-plan outcome
Not yet evaluated
Two peer conditions
peerFailed has trustPath true but peerName other.example.invalid and nameMatch false. Passing a path condition does not compensate for reference-name mismatch.
URL and resolver ledger
Reference public.example.invalid / address supplied
Peer acceptance gate
Trust path true / name match false
Request-plan outcome
Not yet evaluated
Stop the HTTP plan
peerAccepted false leaves requestPlanReady false and httpStatus null. There is no HTTP response; connection rejection is not reported as a server 404 or 500.
URL and resolver ledger
Reference public.example.invalid / address supplied
Peer acceptance gate
Trust path true / name match false
Request-plan outcome
Peer rejected / plan stopped / no HTTP status
Separate the fragment
Parsed hash details is client navigation information; target /notes/tea?view=compact excludes it. Successful URL parsing proves neither DNS, sockets nor certificate validation.
URL and resolver ledger
Target excludes #details
Peer acceptance gate
Trust path true / name match false
Request-plan outcome
Peer rejected / plan stopped / no HTTP status
Channel and authority
Normal peer acceptance and plan readiness can be true while applicationAuthorized stays false. Encryption grants neither private-note authority, session validity nor ownership.
URL and resolver ledger
Target excludes #details
Peer acceptance gate
Accepted peer ≠ application grant
Request-plan outcome
Peer rejected / plan stopped / no HTTP status
Plan versus transmission
Normal requestSent is false; a ready plan is not HTTP delivery. Peer booleans are supplied without executing X509 or TLS, so the conclusion stays at dependency level.
URL and resolver ledger
Target excludes #details
Peer acceptance gate
Accepted peer ≠ application grant
Request-plan outcome
Ready plan / request unsent / crypto unmeasured

Stage boundary

No usable address
noAddress has no usable address and neither transport attempt nor peer evaluation. Without a supplied resolver cause, no timeout or NXDOMAIN diagnosis is added.
URL and resolver ledger
No address / transport and peer unevaluated
Peer acceptance gate
Not yet evaluated
Request-plan outcome
Not yet evaluated
Failed versus not evaluated
Labelling an unevaluated peer check as failed assigns cause to another gate. No application status or certificate error is inserted into this branch.
URL and resolver ledger
No address / transport and peer unevaluated
Peer acceptance gate
Unevaluated peer ≠ rejected peer
Request-plan outcome
Not yet evaluated
No request readiness
noAddress has requestPlanReady false and null HTTP status. No browser result does not prove server receipt or note absence; an earlier stage stopped.
URL and resolver ledger
No address / transport and peer unevaluated
Peer acceptance gate
Unevaluated peer ≠ rejected peer
Request-plan outcome
No plan / no inferred server event
Suitable reuse
Reuse is suitable with freshDns and freshHandshake false. Missing fresh stages are not failure here; suitability of the existing context is supplied.
URL and resolver ledger
Suitable reuse / no fresh DNS or handshake
Peer acceptance gate
Unevaluated peer ≠ rejected peer
Request-plan outcome
No plan / no inferred server event
Transport-type distinction
The selected H1/H2 HTTPS path is TCP+TLS; H3 uses QUIC v1 over UDP without TCP. These alternatives explain protocols; quicExecuted false bounds execution evidence.
URL and resolver ledger
Suitable reuse / no fresh DNS or handshake
Peer acceptance gate
H1/H2 TCP+TLS / H3 QUIC-over-UDP
Request-plan outcome
No plan / no inferred server event
Keep boundaries specific
No address, peer rejection and suitable reuse are distinct outcomes. Collapsing them into retries or fresh-handshake success loses connection-lifecycle information.
URL and resolver ledger
Suitable reuse / no fresh DNS or handshake
Peer acceptance gate
H1/H2 TCP+TLS / H3 QUIC-over-UDP
Request-plan outcome
Discovery / identity / reuse distinct

ASSUMPTION · BOUNDARY · CONTROL

A resolved address is not a trusted service

The normal purpose is to reach the origin selected by the URL. The required trust relationship is validation for the intended service identity. Substituting a DNS answer or reachable transport for that relationship risks sending application data to an unintended peer. The broken assumption is that address discovery authenticates an endpoint. An ordinary other.example.invalid alias produces nameMatch=false here, without connecting to a real server or bypassing validation.

The control preserves the intended hostname throughout connection selection, distinguishes trust/path from name checks, and stops the HTTP plan on a failed peer predicate. This is not a certificate parser test. Even a successful channel leaves application authorization separate: encryption, a public response, or carrying a session cookie grants no private object permission. The scope is the connection identity boundary, not an automatic account compromise from every DNS error.

Do not invent completion of an absent stage

The no-address branch has no usable answer for this fixture. It does not invent a real NXDOMAIN, timeout, or offline diagnosis; only missing observed address information exists. Route and TLS owners remain untouched. Rendering this as HTTP500 or application404 invents a server result before the request reaches a server. Connection failure and application responses carry different evidence.

The reuse branch supplies a suitable existing connection. Absence of fresh DNS and a fresh handshake is therefore not failure. Review asks which connection context, origin, and credential/partition scope made reuse suitable. Forcing every box to animate on every request teaches a false runtime. Browser policy, cache, and connection-management sources constrain the alternatives; the model explicitly names its selected branch.

Read every scenario without motion

Plan controls

Compare URL fields
Raw input, normalized origin, target and hash are calculated separately. Explicit default port does not change origin; query enters the target, fragment does not.
Plan fact ledger
Origin/target/hash distinct
Dependency comparison
Not yet evaluated
Evidence outcome
Not yet evaluated
Bind reference and answer
questionName is intended host and answer address is supplied resolver data. actualDnsQuery is false, so discovery is not reported as an observed DNS exchange.
Plan fact ledger
Origin/target/hash distinct
Dependency comparison
Supplied address / query unexecuted
Evidence outcome
Not yet evaluated
Positive peer control
Normal trustPath and nameMatch yield peerAccepted true. Their conjunction supports readiness while applicationAuthorized and requestSent remain false.
Plan fact ledger
Origin/target/hash distinct
Dependency comparison
Supplied address / query unexecuted
Evidence outcome
Peer accepted / plan ready / app grant false
Three branch evidence
peerFailed is evaluated rejection, noAddress unevaluated, and reuse a suitable context. Evidence stage is identified before any generic status label.
Plan fact ledger
Rejected / unevaluated / reused contexts
Dependency comparison
Supplied address / query unexecuted
Evidence outcome
Peer accepted / plan ready / app grant false
Selector coverage boundary
The selector looks for peerAccepted false with ready true. Normal gives zero and an inconsistent control one; missing observation does not prove a safe channel.
Plan fact ledger
Rejected / unevaluated / reused contexts
Dependency comparison
Contradiction controls / missing coverage separate
Evidence outcome
Peer accepted / plan ready / app grant false
Transition to the next owner
The ledger identifies dependencies passed by the ready plan. HTTP receipt and handling belong to the next capstone and are not added retroactively to the connection plan.
Plan fact ledger
Rejected / unevaluated / reused contexts
Dependency comparison
Contradiction controls / missing coverage separate
Evidence outcome
Plan evidence only / HTTP owner separate

Peer evidence gap

Address-only evidence
The review sees only 203.0.113.10, without route or peer-acceptance records. An address proves neither endpoint identity nor encrypted-channel success.
Plan fact ledger
Address known / route and peer missing
Dependency comparison
Not yet evaluated
Evidence outcome
Not yet evaluated
Do not copy normal results
Normal nameMatch true belongs to another fixture branch. accepted true cannot be recorded for this incomplete event without intended-name and peer-check evidence.
Plan fact ledger
Address known / route and peer missing
Dependency comparison
Expected peer acceptance ≠ observed result
Evidence outcome
Not yet evaluated
Do not invent an HTTP outcome
Readiness and sending remain UNKNOWN, with no HTTP status observed. Neither name failure nor application 404 follows from the address-only record.
Plan fact ledger
Address known / route and peer missing
Dependency comparison
Expected peer acceptance ≠ observed result
Evidence outcome
Plan/send/HTTP outcome UNKNOWN
Required dependency fields
Reference hostname, address source, transport selection, suitable reuse and peer result are needed. Connection errors and server receipts come from separate sources.
Plan fact ledger
Needed: reference/context/peer/recipient
Dependency comparison
Expected peer acceptance ≠ observed result
Evidence outcome
Plan/send/HTTP outcome UNKNOWN
Parser-evidence boundary
A URL API calculates normalized origin, not X509 validation. Native parsing does not replace certificate trust, socket reachability or browser navigation evidence.
Plan fact ledger
Needed: reference/context/peer/recipient
Dependency comparison
URL computation ≠ connection verification
Evidence outcome
Plan/send/HTTP outcome UNKNOWN
Retain the unknown outcome
New observations must answer connection context and peer gating separately. This record retains only the address without adding HTTP readiness or application authority.
Plan fact ledger
Needed: reference/context/peer/recipient
Dependency comparison
URL computation ≠ connection verification
Evidence outcome
Retain address / collect scoped peer evidence

IMPLEMENTATION · SECURITY CONTROL · VERIFICATION

Track dependencies of a request plan

Keep raw input, parsed origin/target, reference hostname, address source, and transport mode separate. Show fragment exclusion using parser output. Compare an explicit :443 or an ordinary query value change to see exactly which record component changes. This check covers a URL API; it establishes neither document navigation policy nor certificate verification.

Connect observation points with typed outcomes: usable address, supplied route predicate, selected protocol, peerValidation, and requestPlanReady. Do not default missing fields to true. Preserve the arrival boundary where a prepared resolver answer has not yet updated browser knowledge. A validated peer result does not become application authorization; the next capstone takes the same plan toward a handler. Readers see known and unknown facts rather than a single status label.

Record failure reasons and trust boundaries

The peer-failed example keeps trustPath=true beside nameMatch=false; an apparently acceptable chain cannot erase a name mismatch. In no-address, the peer check is not evaluated rather than failed. A reused context explains freshHandshake=false together with selectedSuitable=true. These outcomes need not share one retry or error category; the native predicate decides only over supplied ASCII names and booleans.

An XPath over own XML observations selects peerAccepted=false together with requestPlanReady=true. A benign stopped plan matches zero, a deliberately inconsistent inert record matches one, and a missing record proves no safe connection. The selector performs neither time correlation nor TLS transcript decoding. Browser timing, connection errors, and server access observations would be separate real evidence sources; this lesson teaches their decision dependency without fabricating such output.

NOW APPLY IT TO THE CASE

What trust does a DNS answer provide for an HTTPS request?

The public-note URL fragment stays client-side; its request target contains path and query. The supplied DNS answer gives an address, but other.example.invalid does not match the intended peer name. Another branch reuses a suitable connection; each request need not repeat DNS and handshake.

Reconstruct the owner chain from the case records. Attach each observation to its supported outcome without borrowing another request’s success for a missing hop.

Open the related case file ↗

READ THE EXAMPLE TOGETHER

URL and connection decision ledger

Select a field and examine what it supports and where the evidence ends.

Read the raw artifact and field explanations

{
  "input": "https://public.example.invalid/notes/tea?view=compact#details",
  "parsed": {
    "protocol": "https:",
    "hostname": "public.example.invalid",
    "port": "",
    "origin": "https://public.example.invalid",
    "pathname": "/notes/tea",
    "search": "?view=compact",
    "hash": "#details",
    "target": "/notes/tea?view=compact"
  },
  "resolution": {
    "questionName": "public.example.invalid",
    "address": "203.0.113.10",
    "source": "supplied local resolver answer",
    "actualDnsQuery": false
  },
  "normal": {
    "routeAvailable": true,
    "transport": "tcp",
    "httpVersion": "h2",
    "trustPath": true,
    "peerName": "public.example.invalid",
    "nameMatch": true,
    "peerAccepted": true,
    "requestPlanReady": true,
    "applicationAuthorized": false,
    "requestSent": false
  },
  "peerFailed": {
    "trustPath": true,
    "peerName": "other.example.invalid",
    "nameMatch": false,
    "peerAccepted": false,
    "requestPlanReady": false,
    "httpStatus": null
  },
  "noAddress": {
    "usableAddress": false,
    "transportAttempted": false,
    "peerEvaluated": false,
    "requestPlanReady": false,
    "httpStatus": null
  },
  "reuse": {
    "origin": "https://public.example.invalid",
    "suitable": true,
    "freshDns": false,
    "freshHandshake": false,
    "httpVersion": "h2",
    "requestPlanReady": true
  },
  "transportAlternatives": {
    "h1h2": "TCP plus TLS for selected HTTPS path",
    "h3": "QUIC v1 over UDP integrates TLS handshake; no TCP",
    "quicExecuted": false
  },
  "limits": {
    "browserNavigation": false,
    "dnsQuery": false,
    "socketRouteProbe": false,
    "tcpQuicTlsHandshake": false,
    "x509Validation": false,
    "httpDelivery": false,
    "realCredentials": false
  },
  "selector": {
    "language": "XPath",
    "xml": "<audit><plan peerAccepted=\"false\" ready=\"false\"/></audit>",
    "xpath": "count(/audit/plan[@peerAccepted='false' and @ready='true'])",
    "expected": 0,
    "positiveFixtureXml": "<audit><plan peerAccepted=\"false\" ready=\"true\"/></audit>",
    "positiveExpected": 1,
    "scope": "Own inert decision observations, not real vendor logs.",
    "missingFieldBehavior": "Missing observation is insufficient evidence, not a proven healthy or authorized result."
  }
}

parsed: Origin, path, query, and client fragment examined with an actual URL API.
normal: Selected supplied dependency outcomes, not application authority.
peerFailed: Trust/path and name matching are separate predicates.
reuse: A suitable supplied context without a fresh handshake.

Fixed synthetic example; protocol edges are conceptual, and local execution evidence has a separate scope.

Two reality checks

Every HTTPS request performs fresh DNS, TCP, and TLS handshakes.

Caches and suitable connection reuse create other branches; H3 also uses QUIC rather than TCP.

The address resolves and TLS encrypts, so I have permission to the note.

Service identity and channel protection remain separate from application authorization.

YOUR TURN

Work through this story.

Predict the outcome, find the evidence boundary, and explain it in your own words.

The certificate path is trusted, but peerName=other.example.invalid and nameMatch=false. Is the request plan ready for this URL?

No. peerAccepted=false and requestPlanReady=false.
Yes. A trusted path makes hostname checking unnecessary.

Read the explained answer

No. peerAccepted=false and requestPlanReady=false. — A trusted path does not make another service name valid for this URL. No HTTP response is received in this branch, so httpStatus remains null.

Which parts of this URL become the HTTP request target?

Selected lesson artifact fields; teaching example

parsed.pathname: /notes/tea
parsed.search: ?view=compact
parsed.hash: #details
parsed.target: /notes/tea?view=compact

The fragment is included in the target, so the server selects the details route.
/notes/tea?view=compact is sent; #details is not.

Read the explained answer

/notes/tea?view=compact is sent; #details is not. — The target combines path and query. The fragment remains browser context and is not added as a resource path to TLS or DNS.

Reuse has freshDns=false and freshHandshake=false, yet requestPlanReady=true. Why is that possible, and why does readiness not prove application permission or HTTP delivery?

Read the explained answer

A suitable connection can be reused; not every request requires fresh DNS and a handshake. Origin and suitability are supplied conditions here. The normal branch keeps requestSent=false and applicationAuthorized=false: a prepared transport plan is neither a sent request nor application permission. The H3 alternative uses QUIC/UDP, not TCP. No real DNS, socket, TLS or HTTP delivery runs here.

□ I distinguished connection reuse from a fresh handshake per request.

□ I did not treat plan readiness as application permission or delivery.

Open the application console · request / response / browser

Also open request, URL, cookie and DOM examples

Sources and scope

WHATWG URL — Living Standard, 2026-10-074.1. URL representation · 4.4. URL parsing · 6.1. URL class
RFC 1034 — DNS concepts5.3.3. Algorithm
RFC 1812 — IPv4 Router Requirements (historical protocol basis)5.2.4.3 Next Hop Address
RFC 9293 — TCP3.5. Establishing a Connection
RFC 9000 — QUIC v17. Cryptographic and Transport Handshake
RFC 8446 — TLS 1.34.4. Authentication Messages · 4.4.2.4. Receiving a Certificate Message
RFC 9525 — Service Identity in TLS6.1. Constructing a List of Reference Identifiers · 6.2. Preparing to Seek a Match
RFC 9110 — HTTP Semantics7.1. Determining the Target Resource
WHATWG Fetch — Living Standard, 2026-10-062.6. Connections
RFC 9113 — Starting HTTP/23. Starting HTTP/2
RFC 9114 — HTTP/32. HTTP/3 Protocol Overview
OWASP — AuthorizationIntroduction

YOUR NOTES / THIS BROWSER

From URL to a secure connection

1. Core · Mechanism

New connection

Peer mismatch

No address

Connection reuse

Address components belong to different decisions

Separate transport selection from the trusted peer

2. Red · Trust & Impact

Peer name

Stage boundary

A resolved address is not a trusted service

Do not invent completion of an absent stage

3. Blue · Secure development & defense

Plan controls

Peer evidence gap

Track dependencies of a request plan

Record failure reasons and trust boundaries

What trust does a DNS answer provide for an HTTPS request?

Two reality checks

The certificate path is trusted, but peerName=other.example.invalid and nameMatch=false. Is the request plan ready for this URL?

Which parts of this URL become the HTTP request target?

Reuse has freshDns=false and freshHandshake=false, yet requestPlanReady=true. Why is that possible, and why does readiness not prove application permission or HTTP delivery?

Sources and scope