Trace how an HTTP request can use caches, reused connections, intermediaries, and origins without confusing HTTP semantics with network setup.

HTTP Request Lifecycle: From URL to Response

TL;DR

An HTTP request is a request/response exchange, not necessarily a new network connection. Trace a real request by asking which cache, connection, intermediary, and origin stages actually participated.

Do not assume that every request repeats DNS resolution, transport setup, TLS setup, and origin processing. A fresh cache can answer before the network is used, an existing connection can carry another request, and an intermediary cache can answer before the origin application runs.

HTTP/1.1, HTTP/2, and HTTP/3 share HTTP semantics. They differ in how those semantics are carried over the network.

Start with four common request paths

Before memorizing protocol layers, ask which of these shapes resembles the request you are debugging.

1. Fresh client-cache hit

construct request
      ↓
client cache finds a fresh response
      ↓
return stored response

No network request needs to leave the client.

2. Cache miss, existing connection

construct request
      ↓
cache miss
      ↓
reuse suitable connection
      ↓
send HTTP request
      ↓
response

The HTTP request is new even though the connection is not.

3. No suitable connection

The client may need address resolution, transport/connection establishment, and security setup before it can carry the HTTP exchange.

4. Intermediary cache hit

client cache miss
      ↓
network request
      ↓
shared/intermediary cache hit
      ↓
response

origin application processing: skipped

These paths are why there is no single mandatory “DNS → TCP → TLS → app” sequence for every HTTP request.

Keep HTTP semantics separate from network setup

HTTP semantics
request method + target + fields + optional body
                      ↓
response status + fields + optional body

Around that semantic exchange, a client may need caches, connection reuse or setup, intermediaries, and origin processing. DNS, transport, and TLS can affect latency, but they are not the semantics of GET, 404, or Cache-Control.

Cache before network

For the Fetch Standard's default cache mode, Fetch broadly does this on the way to a network fetch:

a matching fresh stored response can be returned without network validation;
a stale stored response may lead to a conditional network request;
a cache miss proceeds toward a normal network fetch.

HTTP caching has more rules than this summary, including authorization interactions, Vary, freshness calculation, and directives. The practical debugging rule is: verify whether the request reached the network before blaming DNS, TLS, a CDN, or backend code.

Connection reuse and setup

When a request must use the network, first ask whether a suitable connection already exists. If one can be reused, that exchange does not need a brand-new transport connection or brand-new secure session.

If no suitable connection exists, setup can include obtaining a usable network address, establishing the required transport, establishing security state for HTTPS, and then carrying the HTTP request. Address caches, connection pools, protocol negotiation, and network environment can skip or alter parts of that work.

HTTP/1.1, HTTP/2, and HTTP/3

RFC 9110 defines semantics shared by the major HTTP versions. The versions differ in message carriage and connection behavior.

HTTP/1.1

HTTP/1.1 expresses HTTP messages using its message syntax over a connection. Connections can be persistent and reused for multiple requests.

HTTP/2

HTTP/2 preserves HTTP semantics while introducing binary framing, field compression, and multiple concurrent exchanges on one connection.

HTTP/3

The practical debugging rule is:

Identify the HTTP version and connection state before inferring which setup work belongs to this request.

Constructing the request

Before an HTTP exchange can happen, the caller needs request semantics: a method, target, fields, and optionally a body.

For a browser Fetch operation, the browser also applies Fetch-specific policy such as request mode, credentials mode, redirect mode, and cache mode. Those policies are part of the browser's fetching model; they are not themselves generic HTTP semantics.

A browser can therefore prevent, redirect, or satisfy a fetch before application code on the origin sees the request.

Intermediaries and origin processing

A request that leaves the client can still encounter several participants before business logic runs:

forward proxy;
CDN or shared cache;
reverse proxy;
API gateway;
load balancer;
service ingress;
origin application.

This is illustrative, not a required topology. When diagnosing a response, ask which participant generated it. Response fields, trace context, server timing, logs, CDN headers, gateway logs, or application correlation IDs can help establish the boundary.

A fast 404 from an edge cache and a 404 generated by application routing have the same HTTP status semantics but very different debugging paths.

Response processing

Receiving bytes successfully over the network does not mean the application operation succeeded. Separate:

network/connection failure — no usable HTTP response was obtained;
HTTP error response — for example 404, 429, or 503;
application-level failure represented inside a nominally successful HTTP response — for example a domain error encoded in a 200 response body.

Once a response exists, a client may stream or buffer its body, update caches, decode content, apply redirect behavior, or expose the result to application code.

A redirect response is still an HTTP response. Following it creates another request whose cache and connection path must be evaluated for the new target.

Try it: Request Path Explorer

The explorer compares predefined request paths. It does not perform live network requests and does not invent representative millisecond timings.

Request Path Explorer

Compare deterministic HTTP request paths without inventing network timings. Each stage states whether it occurs in the selected scenario, is skipped, or depends on deployment/runtime conditions.

HTTP request scenario

The client has no fresh HTTP-cache response and no suitable existing connection. This HTTPS scenario needs new connection and secure-session setup before the HTTP exchange.

Selected request path: Cold HTTPS request: The client has no fresh HTTP-cache response and no suitable existing connection. This HTTPS scenario needs new connection and secure-session setup before the HTTP exchange.

Request path stages

Stage 1Construct requestPerformed
The caller creates the request semantics: method, target URL, headers, body, and relevant browser policy context.
Stage 2Check HTTP cachePerformed
The client checks whether a reusable stored response can satisfy this request. In this scenario the cache lookup misses.
Stage 3Resolve an address if neededConditional
Name resolution is needed only when the client does not already have a usable address result. A cold HTTP connection does not prove that every DNS layer is also cold.
Stage 4Establish transport connectionPerformed
Because no suitable connection exists, the client establishes the transport used by the selected HTTP version, such as TCP for typical HTTP/1.1 or HTTP/2 use, or QUIC for HTTP/3.
Stage 5Establish secure sessionPerformed
This scenario uses HTTPS, so secure-session setup is required for the new connection. TLS is surrounding transport/security work, not the semantics of the HTTP request itself.
Stage 6Send HTTP requestPerformed
The request semantics are carried using the selected HTTP version once a suitable connection is available.
Stage 7Traverse intermediaries if presentConditional
A proxy, CDN, gateway, or load balancer can participate, but HTTP does not require every request to pass through the same intermediary topology.
Stage 8Origin handles requestPerformed
In this scenario no earlier cache satisfies the request, so the origin-side application path produces the response.
Stage 9Receive and process responsePerformed
The client receives the HTTP response status, fields, and body, then applies browser or application response handling such as streaming, caching, or decoding.
Stage 10Construct redirect follow-upSkipped
This response is not a redirect, so no follow-up request is created.

Performed/skipped describes this predefined scenario. Conditional means the stage depends on connection state, cache state, deployment topology, protocol choice, or another condition rather than being guaranteed for every HTTP request.

Use it to answer:

Which stages occurred for this request, which stages were skipped, and which stages depend on runtime or deployment state?

How to debug a slow or surprising request

1. Did a network request occur?

First determine whether a client cache or other local mechanism satisfied the request. If the request never reached the network, DNS, connection establishment, CDN routing, and origin latency are not the cause of this exchange.

2. Was there a redirect or revalidation?

A single user action can cause more than one HTTP exchange. Redirects and conditional validation requests add exchanges that can look like duplicated work unless you inspect statuses and request fields.

3. Was a connection reused?

Check the negotiated protocol and connection information available in your tooling. If the request reused an HTTP/2 or HTTP/3 connection, do not automatically attribute connection-establishment cost to every request carried on that connection.

4. Which participant returned the response?

Distinguish client cache, shared cache/CDN, gateway, reverse proxy, and origin application where your deployment provides evidence for those layers.

5. Where did time accumulate?

Separate, where tooling allows:

waiting for a connection path;
connection/security setup;
request upload;
intermediary/origin processing before response headers;
response body transfer;
client-side processing after bytes arrive.

Tool timing names and precision vary. Treat them as observations from that tool, not universal HTTP fields.

6. What kind of failure occurred?

A DNS failure, TLS/QUIC connection failure, HTTP 503, and domain validation error are different failure boundaries with different owners and retry decisions.

Failure boundaries

Boundary	Example symptom	Next evidence to inspect
Name/address resolution	host cannot be resolved	resolver/network diagnostics
Connection/security setup	connection or certificate/security failure	connection details, TLS/QUIC diagnostics
HTTP intermediary	gateway/CDN/proxy-generated status	intermediary logs and response fields
Origin application	application status/error	application logs, traces, correlation ID
Response body transfer	truncated/aborted stream	network logs, server/client cancellation evidence
Client processing	parse/policy/application failure after response	browser/app logs and Fetch policy context

Do not infer a later boundary when an earlier one already failed. An HTTP 500, for example, proves an HTTP response existed; it is not a DNS failure.

Retries and request semantics

Retry decisions belong to the operation's semantics, not just to whether a transport attempt failed.

HTTP defines method properties such as safety and idempotency, but an application's real side effects still depend on endpoint design. Before retrying a state-changing operation, determine whether it is safe to repeat, whether an idempotency contract exists, whether the previous attempt might have succeeded despite response loss, and which failure classes the retry policy covers.

Exercise

A browser shows an API request with these observations:

the browser reports HTTP/2;
an existing connection identifier is reused;
the request receives 304 Not Modified;
the application service has no normal request-processing log for the resource body;
the browser displays the previously stored representation.

Answer:

Which facts prove that a network HTTP exchange occurred?
Which connection-setup stages can you avoid attributing to this request?
Why does 304 Not Modified not mean “the browser received a second full copy of the body”?
What evidence would you need before claiming the request reached the application service rather than being handled by an intermediary validator?

Agent rule

When debugging or changing code around an HTTP request, do not assume a universal DNS -> connect -> TLS -> origin sequence. Determine whether a cache satisfied the request, whether a suitable connection was reused, which HTTP version carried the exchange, which intermediary or origin generated the response, and whether the observed failure is network-level, HTTP-level, or application-level. Treat DNS, transport, and secure-session setup as adjacent conditional stages, not HTTP semantics themselves.

DNS Resolution — how names become usable network addresses.
TLS and HTTPS — authentication, confidentiality, and secure-session establishment.
HTTP Caching — freshness, validation, cache keys, directives, and shared/private caches.
CDN Behavior — edge routing, shared caching, revalidation, and origin shielding.
Backend Request Lifecycle — what happens after a request reaches service-side application boundaries.
Idempotency — how to make repeated operations safe when retries or ambiguous outcomes are possible.

Sources

Primary references verified on 2026-09-09:

HTTP Request Lifecycle: From URL to Response

Request Path Explorer

Request path stages

On this page